The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2005-Feb> msg00056



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: a question

  • From: "Alok" <alokdube@hotpop.com>
  • Date: Mon, 28 Feb 2005 14:20:55 +0530
  • Resent-Date: Mon, 28 Feb 2005 04:17:32 -0500
  • X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com -----------------------------------------------
  • X-Scanned-By: MIMEDefang 2.45

Hi Rajesh,

Many thanks for your reply,

Please see inline -->

----- Original Message ----- 
From: "Rajesh Pandey" <mrraj_it@yahoo.com>
To: "Alok" <alokdube@hotpop.com>; <mpls-ops@mplsrc.com>
Sent: Sunday, February 27, 2005 4:20 PM
Subject: Re: [MPLS-OPS]: a question


> Hi Alok,
>
> As per my understanding the remote peer need to have a
> unique key to identify or distinguish each and every
> VPLS instance running on that. This key may be based
> on the customer ID, or VLAN or any other parameter
> corresponding that particular FEC.

--> I agree. But the question is if the binding should be created manually
"per node" or end to end? i.e. CPE to CPE.

>This internally can
> map to vc-id for the FEC. Here if you want to bundle
> multiple VPLS instance you can group them for a
> particular vc-id or you can use the group-id field for
> the same. If you don't bind them with a particular
> VC-id it is as good as having multiple FECs so it will
> distribute multiple labels FECs.

--> but then when you bind one customer to one instance and that in turn
provides service to another group of customers, you will have to stack VCIds
in VCIDs,
i.e Increase the frame size, is it not??


Another question, though somewhat unrelated:
If I look at RFC 3630,
I understand there is something called an administrative group, or something
I believe cisco calls as link affinity and Juniper calls as "color".
It is a 4 octect field,

Now consider the following scenario:

R1-------R2
|-----------|

Multiple links between R1 and R2.

What purpose does it serve Network operators to seperate link identity using
colors/admin groups?
Can someone give me a practical application of the same? In other words how
do network operators benefit by using different link groups?

As far as the LSP goes, if it is setup via the upper link of the lower link,
as long as it can work in the constraints, what difference does it make?

I hope someone can help clarify the same.


>
> Regards,
>
> Rajesh
> --- Alok <alokdube@hotpop.com> wrote:
>
> > Hi,
> >
> > Let me clarify my question,
> >
> > I am saying I have a link in between node A and B.
> >
> > All I care about is sending data between A and B.
> >
> > All my circuits are signalled. Not PVCs, RSVP LSPs
> > signalled from say CPEs.
> >
> > Why should on not advertise aggregate bandwidth of
> > the link so that CSPF can
> > look at the whole picture of the link and decide how
> > to setup the LSPs ?
> >
> > -thanks
> > Alok
> > ----- Original Message ----- 
> > From: "Khan, Amjad" <akhan@flagtelecom.com>
> > To: "'Alok'" <alokdube@hotpop.com>
> > Sent: Thursday, February 24, 2005 3:53 PM
> > Subject: RE: [MPLS-OPS]: a question
> >
> >
> > > Alok,
> > > Each Vc has a separate IP addressing? If so, then
> > each VC will have a
> > > separate end-to-end LSP. So you can't bundle them.
> > >
> > > Regards,
> > > Amjad
> > >
> > > -----Original Message-----
> > > From: Alok [mailto:alokdube@hotpop.com]
> > > Sent: 24 February 2005 13:47
> > > To: mpls-ops@mplsrc.com
> > > Subject: [MPLS-OPS]: a question
> > >
> > > Hi,
> > >
> > >
> > > I have a link between 2 nodes A and B.
> > > The link can be further split into 10 different
> > sub component links, vcs
> > but
> > > they are between the same nodes.
> > >
> > > For CSPF computation, does it serve a purpose to
> > advertise each of these
> > > links individually rather than a bundle?
> > >
> > > finally the capacity between 2 links is limited by
> > the baud rate of the
> > > wire. So why are they individually advertised?
> > >
> > > -thanks
> > > Alok
> > >
> > >


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml