RE: [MPLS-OPS]: Nos of Labels in CE

John,

I think the suggestion you propose has already been implemented by at least 
one major router vendor. At least one other major router vendor assigns a 
distinct label per route learned from the CE.

At first glance the label per interface (or label per CE) seems to offer 
scaling advantages in terms of the number of labels that need to be 
supported (if you have issues in your architecture with the number of 
labels that can be supported, that is a clear advantage), however, as 
mentioned, there are issues with carrier supporting carrier and some load 
balancing situations.

For CsC, you could implement your label per CE/interface scheme, then when 
LDP is enabled under a VRF, allocate a label per prefix instead of a label 
per CE. This may be perceived by some operators as inconsistent operation, 
but that is the choice. If you did not do this, there would be no way to 
communicate the destination route (PE) to the egress CE. You can't just 
"pop and forward", because this isn't an IP packet. If you just popped off 
the backbone VPN label, then you'd expose the customer VPN label, which 
wasn't assigned by the egress CE.

For load balancing, consider this case

PE2
|
PE1-------
|            |
R1---Y---R2---Z
|
X

PE1 will advertise routes X, Y, Z to PE2

the best path for X is via R1, so in the label per CE/interface 
implementation it would advertise the label for R1
the best path for Z is via R2, so in the label per CE/interface 
implementation it would advertise the label for R2
Y is equidistant via R1 and R2. Ideally PE1 would loadshare the traffic to 
Y between R1 and R2. Since you can advertise only a single label with the 
route, what label would the label per CE/interface implementation advertise?

Chris

At 09:53 AM 6/20/2003, John Smith wrote:
>Vinay,
>
> > Either you have one label per route and associate the next hop L2
> > information (usually the destination mac address) with the label and 
> save it
> > in the lookup table OR you pop the label and do a lookup on the IP DA to
> > figure out the next hop that you can ARP (assuming it is still ethernet) to
> > get the next hop L2 information.
>
>The latter suits fine to me.
>
> >
> > However, if you have point to point link (say PPP) as the outgoing
> > interface, then it might make some sort of sense to associate label binding
> > for IP routes based on outgoing links. But if you do that you lost your
> > ability to load balance unless you can figure out a way to associate
> > multiple label bindings for the same IP routes emanating from different
> > interfaces.
>
>I think i wasnt clear in stating my problem. What i want to do is to bind 
>a label to an
>interface, rather than the routes which i recieve. Say, i have a BGP CE 
>peering over an
>interface - What this means is that my BGP peering takes place through one 
>interface. I
>will now bind one label Lx for this interface. I will be advertising this 
>label for all
>the routes which i learn from this peer as i know it will always be this 
>peer which i
>will use as my next-hop (as its an EBGP peer).
>
>Is this correct?
>
>Is it okay to associate a Label Lx with a BGP CE peer (implicitly an 
>interface) and to
>always use when i need to advertise routes learnt from this peer.
>
>Lets verify that data forwarding will be done correctly?
>
>If this router recieves a MPLS packet with the BGP label as Lx, it will 
>simply pop off
>this label and push the native IPv4 packet on the interface over which the 
>BGP peering
>takes place. This packet when reaches the EBGP CE peer, will decide where 
>it needs to
>forward this packet.
>
>I think it works fine - and thus my idea of binding an interface to a Label!!
>
>Does anyone see any problems in this?
>
>Regards,
>JOhn Smith
>
>
>
>
>________________________________________________________________________
>Want to chat instantly with your online friends?  Get the FREE Yahoo!
>Messenger http://uk.messenger.yahoo.com/