Subject: RE: Doubt in BGP for L3 VPNs

From: John Smith <[email-masked]>
Date: Thu, 14 Apr 2005 03:08:30 +0100 (BST)

Hi Rajiv,

> When the UPDATE carries MP_REACH_NLRI, the NEXT_HOP attribute should not
> be carried since the NEXT_HOP information is encoded inside the
> MP_REACH_NLRI. This is needed so that the same UPDATE can pack multiple
> MP_REACH_NLRI (that may have different NEXT_HOPs). Please take a look at
> the RFC2283.

I understand the point that NEXT_HOP is not mandatory when we have MP_REACH_NLRI path
attribute, but there are a lot of implementations in the wild that do advertise the
NEXT_HOP nevertheless. Any sane implementation will NOT get bothered with a NEXT_HOP in
the UPDATE message when there are only multiprotocol NLRIs to process.

> 
> > Now, we want all the BGP labelled packets to terminate at the 
> > RR viz PEz. 
> 
> Could you please explain "why" ?

I did that in my other mail. I'll do it once more.

PEx -- RR -- PEy

PEy does not have a MPLS tunnel till PEx. It has it only till the RR. In this case, PEy
will not be able to install routes learnt from PEx (using 2547) as it will not be able to
resolve the next-hop. In such cases, an admin can manually set the next-hop-self on RR so
that RR sets the NEXT_HOP to itself in all the MPBGP NLRIs that it advertises to PEy. PEy
will now be able to accept the L3 VPN prefixes because the next-hop in MP_REACH_NLRI is
resolvable.

> 
> > Is this correct? We find that the outer NEXT_HOP gets 
> > converted to that of the RR, but the internal still points to 
> > PEx. Is this vendor behavior incorrect or is there a flaw in 
> > our understanding?
> 
> By definition, the RR is not supposed to change the NEXT_HOP.

But there is nothing that forbids it from doing that! In fact, there could be scenarios
when it becomes vital for the RR to do that. One case which i can think of at the top of
my head right now is when you want to enforce the RR to come in the forwarding path.
There could be zillion reasons why you may want that to happen, security, QoS,
predictability in the path being taken in case you have equal cost BGP routes originating
from your behind, etc.

Thanks,
John

> 
> Cheers,
> Rajiv
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of John Smith
> > Sent: Wednesday, April 13, 2005 8:18 PM
> > To: [email-masked]
> > Subject: Doubt in BGP for L3 VPNs
> > 
> > Hi,
> > 
> > PEx -- PEz -- PEy
> > 
> > This is in the context of L3 VPNs. PEz is a BGP route 
> > reflector connected to two clients PEx and PEy (its also 
> > connected to other PE routers which i have omitted for the 
> > sake of clarity).
> > 
> > By default, PEy recieves all BGP UPDATEs from PEx which have 
> > PEx as the NEXT_HOP. This happens for the NEXT_HOP attribute 
> > in the BGP UPDATE message and also for the next-hop that is 
> > encoded inside MP_REACH_NLRI. This way, PEy knows that it 
> > needs to put an outer label that corresponds to the router PEx.
> > 
> > Now, we want all the BGP labelled packets to terminate at the 
> > RR viz PEz. So, we configured next-hop-self on the RR 
> > thinking that it will change the NEXT_HOP path attribute 
> > carried in the BGP UPDATE message and that carried inside the 
> > MP_REACH_NLRI to that of the PEz. 
> > 
> > Is this correct? We find that the outer NEXT_HOP gets 
> > converted to that of the RR, but the internal still points to 
> > PEx. Is this vendor behavior incorrect or is there a flaw in 
> > our understanding?
> > 
> > Thanks,
> > John
> > 
> > Send instant messages to your online friends 
> > http://uk.messenger.yahoo.com 
> > 
> 
> 

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 13 Apr 2005 20:25:52 -0700

Hi John,

Sure you are correct. There is no problem with RRs setting next hop to 
self even for VPN routes.

The problem is with forwarding traffic ... you need to install the VPN 
labels into LFIBs and swap on them. Simply it requires an ASBR like 
functionality when inter-as option B is used. The difference is that 
here this is all one AS but the forwarding plane this is transparent.

In your case when nhs is set for RR the IGP will be impl-null label so 
will not exist. When the topology grows you also need to consider 
imposing IGP/LDP label when swapping VPN packets at the RR.

Is your doubt resolved ?

Cheers,
R.

 > John Smith wrote:

---

From: "Steve Yao" <[email-masked]>
Date: Sun, 17 Apr 2005 11:19:42 -0500

John,

If you want to enforce the RR to be in the forwarding path, would it be more
convenient to
set up explicit-routed LSPs between PEx and PEy that go through the RR?

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
John Smith
Sent: Wednesday, April 13, 2005 9:09 PM
To: Rajiv Asati (rajiva); [email-masked]
Subject: RE: Doubt in BGP for L3 VPNs

Hi Rajiv,

> MP_REACH_NLRI (that may have different NEXT_HOPs). Please take a look at

I understand the point that NEXT_HOP is not mandatory when we have
MP_REACH_NLRI path
attribute, but there are a lot of implementations in the wild that do
advertise the
NEXT_HOP nevertheless. Any sane implementation will NOT get bothered with a
NEXT_HOP in
the UPDATE message when there are only multiprotocol NLRIs to process.

PEx -- RR -- PEy

PEy does not have a MPLS tunnel till PEx. It has it only till the RR. In
this case, PEy
will not be able to install routes learnt from PEx (using 2547) as it will
not be able to
resolve the next-hop. In such cases, an admin can manually set the
next-hop-self on RR so
that RR sets the NEXT_HOP to itself in all the MPBGP NLRIs that it
advertises to PEy. PEy
will now be able to accept the L3 VPN prefixes because the next-hop in
MP_REACH_NLRI is
resolvable.

> By definition, the RR is not supposed to change the NEXT_HOP.

But there is nothing that forbids it from doing that! In fact, there could
be scenarios
when it becomes vital for the RR to do that. One case which i can think of
at the top of
my head right now is when you want to enforce the RR to come in the
forwarding path.
There could be zillion reasons why you may want that to happen, security,
QoS,
predictability in the path being taken in case you have equal cost BGP
routes originating
from your behind, etc.

Thanks,
John

---

From: Spice Sylvia <[email-masked]>
Date: Mon, 18 Apr 2005 12:23:13 +0100 (BST)

Hi,

What could be more explicit than physically placing it
in the forwarding path and setting next-hop to self?

May I understand the need for an "LSP" in this case?

-brgds
Sylvia

 --- Steve Yao <[email-masked]> wrote: 
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> John Smith

---

From: "Steve Yao" <[email-masked]>
Date: Mon, 18 Apr 2005 12:22:21 -0500

Sylvia,

My understanding of the issue is to put the RR in the forwarding path
AND to allow the L3VPN forwarding to work. Like mentioned previously by
others,
you need to have a forwarding entry such that the VPN label pushed
by PEy will be eventually presented at PEx. Setting up an LSP from PEy
to PEx is certainly one option here.

But if you say you don't want the VPN labeled packets to go to PEx at all,
then there
is no need for the LSP. But then the question is what is it that you are
trying to do?

Steve

-----Original Message-----
From: Spice Sylvia [mailto:[email-masked]]
Sent: Monday, April 18, 2005 6:23 AM
To: Steve Yao; John Smith; Rajiv Asati (rajiva); [email-masked]
Subject: RE: Doubt in BGP for L3 VPNs

Hi,

-brgds
Sylvia

 --- Steve Yao <[email-masked]> wrote:
> [mailto:[email-masked]]
> > > On Behalf Of John Smith

---

From: Spice Sylvia <[email-masked]>
Date: Mon, 18 Apr 2005 20:23:12 +0100 (BST)

Steve,

This is the one case whose behaviour I am trying to
clarify.

Take the case where the RR acts as both the P and PE
router.
The same RR can be an PE+transit for some customer
scenarios, the label mapping can be carried by BGP for
both cases.

for example:
            CE     CE 
             |      |
            PE     PE
             |      |
CE---PE-----RR-----RR----PE--CE
             |      |
            CE     CE

This CEs all belong to the same VPN. Rather than use a
seperate mechanism to signal a P2P LSP across PEs, let
BGP carry the association, by mapping traffic/prefixes
to the appropriate customer VRFs.

You agree that the VRFs in the middle on the RRs has
to have VPN routes of all PEs in that VPN?

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