[bess] RFC 9489 on Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN)

A new Request for Comments is now available in online RFC libraries. RFC 9489 Title: Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) Author: P. Jain,

[bess] The significance of bypassing DF Election Behavior in the EVPN Fast Reroute draft

Luc and all,https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.1 I have a question regarding significance of bypassing DF Election behavior in Section 5.1 of the EVPN Fast Reroute draft, at least in the case of All-Active multi-homing and EVPN-MPLS. To the be

[bess] Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

Christian and all, Repeating the gist of my comments on the PLE Signaling draft at the MPLS WG session in Prague today. I think that Endpoint-ID defined in Section 5.5. of this draft is not needed. If you want the endp

Re: [bess] Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

Christian and Sasha, Section 7 of RFC 4842 discusses the actions taken when you have trace mismatch conditions as well as other SONET/SDH-layer failures. Perhaps this text should be adapted to draft-ietf-pals-ple as well. Cheers, Andy On Thu, Nov 9, 2023 at 8:34 AM Alexander Vainshtein < alexan

Re: [bess] [EXTERNAL] Re: Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

Andrew hi! Very glad to hear from you! I have looked up Section 7 of RFC 4842, and I fully agree that the draft should define equivalent behavior (where applicable) for both Private Line to PSN and PSN to Private Line directions. These a

Re: [bess] The significance of bypassing DF Election Behavior in the EVPN Fast Reroute draft

Hi Sasha, BUM is not in-scope of the draft, it is not redirected; The Fast-Reroute draft describes 2 behaviours, terminal disposition and NDF-bypass. The mechanism is agnostic to the load-balancing mode: one, the other, or both behaviours may be applicable. You are right, in A/A the “NDF-bypas

Re: [bess] [EXTERNAL] Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

Hi Alexander and Andy, Yes, very useful comments indeed ! Totally agree in case a “misconnection” is detected a downstream fault indication signal such as AIS or LF must be inserted, I meant to cover that but it somehow slipped through the cracks so far. Btw I would further propose to follow

[bess] Clarification on the draft: draft-ietf-bess-evpn-vpws-fxc-08

Hello, In section 3.2 of the draft: draft-ietf-bess-evpn-vpws-fxc-08 the “Default Flexible Xconnect” is described. This section defines the single homing case, while section 3.2.1 describes the multihoming case. Is it allowed to have more than one Vlan-Bundle on the same VPWS service tunnel? I

Re: [bess] Comments on draft-malhotra-bess-evpn-centralized-anycast-gw

Hi Jorge, Many thanks for the review. Please see inline: # Major comment: I believe section 5.1 is not correct: “... GW MAC/IP MUST be advertised with a higher sequence number. ...” And as per draft 7432bis: “MAC Mobility extended community SHALL NOT be attached to routes which also have De

Re: [bess] [EXTERNAL] Endpoint-ID in draft https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-00

Christian and all, ++ Adrian. Please note that Path Trace ID mismatch in SONET/SDH and OTN is a data plane feature: * The configured Tx Trace Identifier string is carried in the corresponding overhead * The SONET/SDH/OTN framers are configured with both the Expected Rx Trace Identifier