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 <bess-boun...@ietf.org> on behalf of Gyan Mishra <hayabusa...@gmail.com> Date: Thursday, December 12, 2019 at 11:01 AM To: michael walden <michaelewal...@gmail.com> Cc: "bess@ietf.org" <bess@ietf.org>, Robert Raszuk <rob...@raszuk.net> Subject: Re: [bess] RFC 8277 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 <michaelewal...@gmail.com<mailto:michaelewal...@gmail.com>> 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<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 <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> wrote: 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 <rob...@raszuk.net<mailto:rob...@raszuk.net>> 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 <michaelewal...@gmail.com<mailto:michaelewal...@gmail.com>> 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<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. R1-----eBGP- VPNv4-----R2-----iBGP VPNv4-----R3 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. R1-----eBGP- VPNv4-----R2-----iBGP VPNv4-----R3 _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> 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: gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> 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: gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
