/* 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>
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
>
>
>
>
>
>
>
>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to