Subject: Re: [bess] RFC 8277

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Dec 2019 17:55:25 +0100

/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second
implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only
local significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is
quite surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden <[email-masked]>
wrote:

>
> Regarding RFC 8277 Section 3.2.2
> 3.2.2.  When the Next Hop Field Is Changed
>
>    If the Network Address of Next Hop field is changed before a SAFI-4
>    or SAFI-128 route is propagated, the Label field(s) of the propagated
>    route MUST contain the label(s) that is (are) bound to the prefix at
>    the new next hop.
>
>
> "the Label field(s) of the propagated route MUST contain the label(s) that
> is (are) bound to the prefix at the new next hop."
>
> This specification should apply when the next hop field of the route is
> changed by any means such as route map, route policies, or next-hop-self
> and propagated?
>
> I've experienced differing behaviors between platforms as to whether or
> not a the label is changed when the next hop field is changed with a route
> map or route policy.
>
> For example below inter-as option b R2 receives VPNv4 route 1.1.1.1/32
> with label 1 from R1.  R2 changes the next hop field with an outbound route
> policy but doesn't replace the label before propagating the route to R3.
> R3 receives VPNv4 route 1.1.1.1/32 and original label 1 breaking the LSP.
>
> R1-----eBGP- VPNv4-----R2-----iBGP VPNv4-----R3
>
>
> However on other platforms inter-as option b R2 receives VPNv4 route
> 1.1.1.1/32 with label 1 from R1.  R2 changes the next hop field with an
> outbound route policy and does replace the label before propagating the
> route to R3.  R3 receives VPNv4 route 1.1.1.1/32 and new label 2.
>
> R1-----eBGP- VPNv4-----R2-----iBGP VPNv4-----R3
>
>
>
>
>
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Dec 2019 12:48:45 -0500

With option b since the LSP is segmented into 3 segments

Left side Rx to R1 -ibgp
Middle R1 to R2 - ebgp vpnv4
Right side R2 to R3 - ibgp

So for the LSP to be segmented in opt b for it to work properly what is
required is either next-hop-self on the ibgp peer so the rewrite happens
forcing the label to change so the lsp is segmented on left side and right
side from the middle.  The reason also for the segmentation in opt B is we
are not importing the  SP loops between each other as done with opt c so
the segmentation of the lsp has to happen for opt b to work.

If you are doing this on Cisco XR it requires next hop static /32  route
for MPLS forwarding to happen on the ebgp vpnv4 session where with XE
automatically installs “MPLS forwarding” when ebgp vpnv4 is configured.

If the rewrite is not happening to segment the lsp generate a new label
then sounds like you are hitting a big.

The inter as opt a b c ab are all IETF standards and the functionality and
behavior should be the same across all vendors.

Cheers,

Gyan

On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk <[email-masked]> wrote:

>> "the Label field(s) of the propagated route MUST contain the label(s)
>> that is (are) bound to the prefix at the new next hop."
>>
>> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Dec 2019 13:58:10 -0500

I can try it out in VIRL.

What version of XR or XE are you running?

On Thu, Dec 12, 2019 at 1:52 PM michael walden <[email-masked]>
wrote:

> Thank you for the responses.  This is specifically not using next hop self
> to change the next hop, but using a route map or RPL to set next hop to a
> specific IP value such as below.  I realize this probably isn't a common
> configuration.
>
> route-map NH permit 10
>  match ip address prefix-list ONE
>  set ip next-hop x.x.x.x
>
> route-policy NH
>   if destination in (1.1.1.1/32) then
>     set next-hop x.x.x.x
>
> On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra <[email-masked]>
> wrote:
>
>>
>>
>> The inter as opt a b c ab are all IETF standards and the functionality
>> and behavior should be the same across all vendors.
>>
>> Cheers,
>>
>> Gyan
>>
>>>> 1.1.1.1/32 with label 1 from R1.  R2 changes the next hop field with
>>>> an outbound route policy and does replace the label before propagating the
>> 13101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
>> FDC1 3rd Floor
>>
>> Silver Spring, MD 20904
>>
>> United States
>>
>> Phone: 301 502-1347
>>

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Thu, 12 Dec 2019 19:25:33 +0000

Hi,

If the next-hop is set to some third-party device at the option-B ASBR and a new label is advertised, then we have to make sure that at that third-party device, the particular prefix is in fact bound to that particular label. Therefore, in addition to setting the next-hop at the ASBR there needs to be a way to specify the particular label also.

Otherwise just using any dynamic label will not work.

Thanks,
--Satya

From: BESS <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Thursday, December 12, 2019 at 11:01 AM
To: michael walden <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>
Subject: Re: [bess] RFC 8277

On Thu, Dec 12, 2019 at 1:52 PM michael walden <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for the responses.  This is specifically not using next hop self to change the next hop, but using a route map or RPL to set next hop to a specific IP value such as below.  I realize this probably isn't a common configuration.

route-map NH permit 10

route-policy NH
  if destination in (1.1.1.1/32<http://1.1.1.1/32>) then
    set next-hop x.x.x.x

On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

Left side Rx to R1 -ibgp

So for the LSP to be segmented in opt b for it to work properly what is required is either next-hop-self on the ibgp peer so the rewrite happens forcing the label to change so the lsp is segmented on left side and right side from the middle.  The reason also for the segmentation in opt B is we are not importing the  SP loops between each other as done with opt c so the segmentation of the lsp has to happen for opt b to work.

If you are doing this on Cisco XR it requires next hop static /32  route for MPLS forwarding to happen on the ebgp vpnv4 session where with XE automatically installs “MPLS forwarding” when ebgp vpnv4 is configured.

If the rewrite is not happening to segment the lsp generate a new label then sounds like you are hitting a big.

The inter as opt a b c ab are all IETF standards and the functionality and behavior should be the same across all vendors.

Cheers,

Gyan

On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only local significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is quite surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden <[email-masked]<mailto:[email-masked]>> wrote:

"the Label field(s) of the propagated route MUST contain the label(s) that is (are) bound to the prefix at the new next hop."

This specification should apply when the next hop field of the route is changed by any means such as route map, route policies, or next-hop-self and propagated?

I've experienced differing behaviors between platforms as to whether or not a the label is changed when the next hop field is changed with a route map or route policy.

For example below inter-as option b R2 receives VPNv4 route 1.1.1.1/32<http://1.1.1.1/32> with label 1 from R1.  R2 changes the next hop field with an outbound route policy but doesn't replace the label before propagating the route to R3.  R3 receives VPNv4 route 1.1.1.1/32<http://1.1.1.1/32> and original label 1 breaking the LSP.

However on other platforms inter-as option b R2 receives VPNv4 route 1.1.1.1/32<http://1.1.1.1/32> with label 1 from R1.  R2 changes the next hop field with an outbound route policy and does replace the label before propagating the route to R3.  R3 receives VPNv4 route 1.1..1.1/32<http://1.1.1.1/32> and new label 2.

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess
--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>

--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Dec 2019 20:33:13 +0100

Hi Satya,

I believe the address Michael is using in the route-map to set nh is one of
the local addresses on the very ASBR.

Thx,
R.

On Thu, Dec 12, 2019 at 8:25 PM Satya Mohanty (satyamoh) <[email-masked]>
wrote:

> Hi,
>
>
>
> If the next-hop is set to some third-party device at the option-B ASBR and
> a new label is advertised, then we have to make sure that at that
> third-party device, the particular prefix is in fact bound to that
> particular label. Therefore, in addition to setting the next-hop at the
> ASBR there needs to be a way to specify the particular label also.
>
>
>
> *From: *BESS <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Thursday, December 12, 2019 at 11:01 AM
> *To: *michael walden <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>
> *Subject: *Re: [bess] RFC 8277
>
>
>
>
>
>
>
> route to R3.  R3 receives VPNv4 route 1.1..1.1/32 <http://1.1.1.1/32> and
> new label 2.
>

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Thu, 12 Dec 2019 20:02:44 +0000

Thanks Robert.
Yes, I made a general observation.

Best,
--Satya

From: Robert Raszuk <[email-masked]>
Date: Thursday, December 12, 2019 at 11:34 AM
To: "Satya Mohanty (satyamoh)" <[email-masked]>
Cc: Gyan Mishra <[email-masked]>, michael walden <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] RFC 8277

Hi Satya,

I believe the address Michael is using in the route-map to set nh is one of the local addresses on the very ASBR.

Thx,
R.

On Thu, Dec 12, 2019 at 8:25 PM Satya Mohanty (satyamoh) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,
--Satya

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 12, 2019 at 11:01 AM
To: michael walden <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] RFC 8277

route-map NH permit 10

route-policy NH

Left side Rx to R1 -ibgp

Cheers,

Gyan

Hi Michael,

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 12 Dec 2019 18:42:43 -0500

I believe changing the next-hop re-write normally done via next-hop-self
which sets the next hop to the ibgp peering loopback of the PE done in Opt
B can be accomplished via route policy route-map or RPL to set to the same
loopback or different address  via “set ip next-hop.

I think as was mentioned the label binding is not being created to the new
next hop address as was mentioned.

Verify that the label binding is not being created for the rewritten new
next hop address.

Try remove the policy and do next hop self and then check if label binding
is being created.

I have used route policy to set next hop but have never done for opt B.

I think this maybe a corner case issue bug

On Thu, Dec 12, 2019 at 3:06 PM michael walden <[email-masked]>
wrote:

> Yes, it's a local address on ASBR R2 which is the same router changing the
> next hop.  I was trying to find out from a standards perspective if
> changing the next hop field in this manner should also change the label
> since I'm seeing different behavior on different network operating systems.
>
> On Thu, Dec 12, 2019 at 2:33 PM Robert Raszuk <[email-masked]> wrote:
>
>> Hi Satya,
>>
>> On Thu, Dec 12, 2019 at 8:25 PM Satya Mohanty (satyamoh) <
>> [email-masked]> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> If the next-hop is set to some third-party device at the option-B ASBR
>>> and a new label is advertised, then we have to make sure that at that
>>> Thank you for the responses.  This is specifically not using next hop
>>> self to change the next hop, but using a route map or RPL to set next hop
>>> to a specific IP value such as below.  I realize this probably isn't a
>>> common configuration.
>>>
>>>
>>>
>>> route-map NH permit 10
>>> route to R3.  R3 receives VPNv4 route 1.1..1.1/32 <http://1.1.1.1/32>
>>> and new label 2.
>>>

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347