Subject: Question on nexthop/label in CsC/Multi-AS scenarios

From: Jeff Helmer <[email-masked]>
Date: Fri, 20 Feb 2004 12:32:17 -0800 (PST)

I have a question related to setting of the nexthop/label in Carrier's Carrier or Multi-AS scenario. Consider scenario below:
 
        CsC-PE
            |
--------------------------
     |           |
   CE1      CE2
     |           |
---------------------------
           |
          PE
 
CsC-PE is in AS 100 and CE1, CE2 and PE are in AS 200.
 
If CE1 advertised route X to CsC-PE with label L1 and CsC-PE selected the route in the VRF, when it advertises the route to CE2, does it follow the regular nexthop rules and advertise CE1 as the nexthop? If so, does it use the same label L1? Or, will CsC-PE allocate its own label and advertise itself as the nexthop to CE2?
 
The same question arises when CE1 gets a route Y with label L2 from CsC-PE and has to advertise it to PE. Would CE1 allocate its own label and advertise itself as the nexthop to PE or would it advertise the EBGP peer (CsC-PE) as the nexthop and expect PE to have a label-switched path to CsC-PE?
 
Is the above implementation dependent?
 
- Jeff

---------------------------------
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 20 Feb 2004 13:43:59 -0800 (PST)

> If CE1 advertised route X to CsC-PE with label L1 and CsC-PE
> selected the route in the VRF, when it advertises the route to CE2,
> does it follow the regular nexthop rules and advertise CE1 as the
> nexthop?

In a multi-access link (e.g. shared ether segment), it should, imho... 
If these are two different links it cannot.

> If so, does it use the same label L1?
assuming shared link scenario, yes.

Labels are next-hop specific.

Whenever the nexthop is changed the label must change (and stiching
state is created). A router cannot change the label and not the
next-hop... i.e. it can't assign a label in behalf of somebody else.

> Or, will CsC-PE allocate its own label and advertise itself as the nexthop to CE2?

If the 3rd party next-hop check fails (!= links) or nexthop self is
configured, that would be the case. As with unlabeled BGP.

>  
> The same question arises when CE1 gets a route Y with label L2 from
> CsC-PE and has to advertise it to PE. Would CE1 allocate its own label
> and advertise itself as the nexthop

CE1 is most likely doing next-hop self given that there is typically
the assumption that label signaling doesn't extend to the
inter-provider link...

> to PE or would it advertise the EBGP peer (CsC-PE) as the nexthop
> and expect PE to have a label-switched path to CsC-PE?

That typically doesn't happen... you could however configure a system
that way.

> Is the above implementation dependent?

The defaults in terms of next-hop self config are implementation
dependent.

The behaviour of allocating labels when next-hop changes is a property
of mpls.

Whether you have label FECs for the address of the peer is a network
design decision.

  Pedro.

---

From: Jeff Helmer <[email-masked]>
Date: Fri, 20 Feb 2004 14:28:51 -0800 (PST)

Pedro,
 
Thanks for your response. The summary I understood is that the rules for setting the nexthop are roughly the same for both unlabeled IPv4 and labeled IPv4 route exchange. The possible exception is when advertising route learnt from EBGP to IBGP peers - if sending labels with the route, it appears best to set the nexthop to self (with appropriate label allocation and stitching).
 
I have a similar question related to Multi-AS 10(c) scenario. 
 
Consider the diagram below where the multihop EBGP VPN peering is between PEx and PEy. If PEx learns of route Rd1:X from PEy, should it set the nexthop to self or not before advertising to PE1? If it set nexthop to self, the PE1 may be unnecessarily sending the packet to PEx instead of directly sending towards PEy in the adjacent AS.

-- PE1 -- P --- ASBR1 ---- ASBR2 -- P -- PE2
          |                         |
          |                         |
         PEx                        PEy
 
If PEx were to pass the VPN route with nexthop unchanged, how will Multi-AS scenario 10(b) work? It appears PEx needs a default behavior (e.g., next-hop-self) and user configuration is needed for one of the two scenarios. Am I totally off the mark?
 
- Jeff

Pedro. 

---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 20 Feb 2004 14:53:15 -0800 (PST)

> Consider the diagram below where the multihop EBGP VPN peering is
> between PEx and PEy. If PEx learns of route Rd1:X from PEy, should it
> set the nexthop to self or not before advertising to PE1?

Both options are availiable from a standards point of view. Its a
design decision...

Typically that decision would depend on wether PE1 has a FEC for
PE2/32.

If you are doing option 10 c) then one would by default configure PEx
and PEy to not modify the next-hop.

i.e. this would be the equivalent of iBGP RRs.

> If it set
> nexthop to self, the PE1 may be unnecessarily sending the packet to
> PEx instead of directly sending towards PEy in the adjacent AS. 
>  
>  
> If PEx were to pass the VPN route with nexthop unchanged, how will
> Multi-AS scenario 10(b) work?

10(b) assumes that the exchange of routes and traffic is being
performed by the ASBRs, not PEx & y.

> It appears PEx needs a default behavior
> (e.g., next-hop-self) and user configuration is needed for one of the
> two scenarios. Am I totally off the mark? 

It would be reasonable to default to next-hop for EBGP if the session
is directly connected (common 10b scenario) and default not to for
multihop (common 10c scenario).

Implementations may not get all the nuances right ;-)

  Pedro.