The MPLS-OPS Archive

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



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

RE: a question

  • From: "Javier Antich Romaguera" <jantich@juniper.net>
  • Date: Mon, 28 Feb 2005 09:33:41 -0000
  • Resent-Date: Mon, 28 Feb 2005 04:58:22 -0500
  • X-MIME-Autoconverted: from quoted-printable to 8bit by host.secure4-hosting.net id j1S9Xmcw015263
  • X-OriginalArrivalTime: 28 Feb 2005 09:33:43.0028 (UTC) FILETIME=[97D13B40:01C51D78]
  • X-Scanned-By: MIMEDefang 2.45

Hi Alok, 
    with admin groups/colors you can add arbitrary binary properties to your network links that can be used on the LSP setup decision process (CSPF) to selectively include/exclude links on the path you want to setup. 
    Applications of this are many.
          Color links based on Class of service.
          Color links based on Services you want them to transport.
          Color links based on load balancing criteria.
          Color links based on its reliability.
          ... 
          or any combination of the above.
 
>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?

If the links are identical and both match the constraints, probably there is not much difference. If they are not equal, then there may be delay differences, even reliability differences, etc. 
 
Cheers
Javier.
 
 

----------------------------------------------------------------------

Javier Antich Romaguera

Systems Engineer Tech Lead

Juniper Networks.

email: jantich@juniper.net <mailto:jantich@juniper.net>  

phone: +34 91 503 02 33

mobile: +34 639 218 428

fax: +34 91 503 0582

----------------------------------------------------------------------

 

   

________________________________

From: Alok [mailto:alokdube@hotpop.com]
Sent: Mon 28/02/2005 08:50
To: mpls-ops@mplsrc.com
Subject: Re: [MPLS-OPS]: a question



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



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