[bess] I-D Action: draft-ietf-bess-vpls-multihoming-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : BGP based Multi-homing in Virtual Private LAN Service Authors : Bhupesh Kothari Kireeti Kompella Wim Henderickx Florin Balus James Uttaro Filename: draft-ietf-bess-vpls-multihoming-05.txt Pages : 21 Date: 2019-07-26 Abstract: Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-vpls-multihoming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-vpls-multihoming-05 https://datatracker.ietf.org/doc/html/draft-ietf-bess-vpls-multihoming-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-vpls-multihoming-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] FW: New Version Notification for draft-snr-bess-pbb-evpn-isid-cmacflush-06.txt
We just updated this draft with the security considerations. As discussed by the WG chairs this week, it's ready for WG adoption call. Comments are welcome. Thanks. Jorge A new version of I-D, draft-snr-bess-pbb-evpn-isid-cmacflush-06.txt has been successfully submitted by Jorge Rabadan and posted to the IETF repository. Name: draft-snr-bess-pbb-evpn-isid-cmacflush Revision: 06 Title: PBB-EVPN ISID-based CMAC-Flush Document date: 2019-07-26 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-snr-bess-pbb-evpn-isid-cmacflush-06.txt Status: https://datatracker.ietf.org/doc/draft-snr-bess-pbb-evpn-isid-cmacflush/ Htmlized: https://tools.ietf.org/html/draft-snr-bess-pbb-evpn-isid-cmacflush-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-snr-bess-pbb-evpn-isid-cmacflush Diff: https://www.ietf.org/rfcdiff?url2=draft-snr-bess-pbb-evpn-isid-cmacflush-06 Abstract: Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) to deploy ELAN services in very large MPLS networks (PBB- EVPN). Single-Active Multi-homing and per-ISID Load-Balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active Multi-Homed Ethernet Segments, PBB-EVPN defines a CMAC-Flush mechanism that works for different Ethernet Segment BMAC address allocation models. This document complements those CMAC-Flush procedures for cases in which no PBB-EVPN Ethernet Segments are defined (ESI 0) and an ISID-based CMAC-Flush granularity is desired. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Comment at the mic
Hey Keyur, I would like to share my perspective on your comment made at the BESS yesterday. What you pointed out that VPN demux should be removed or renewed when we rewrite bgp next hop is very true in 4364 world or even in EVPN world where VPN label is of local significance. But in Srihari's proposal VPN demux may be of domain wide significance hence mandating its removal at each EBGP boundary in the spec would be a bad hint. See with SID indicating to which VRF packet belongs applied consistently by say NMS your option C becomes seamless without any "next-hop-unchanged" hacks nor making PE-PE for multihomed sites failover requires any fancy shadow LFIBs or control plane "taps" into updates which just pass by. So while in general my personal opinion is that we do not need yet one more way of protocol encoding to accomplish L3VPNs which already is shipping in the form of 4364 and EVPN standards if WG decides to proceed let's learn from the past experience here. Cheers, R. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
