[bess] I-D Action: draft-ietf-bess-vpls-multihoming-03.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-03.txt Pages : 21 Date: 2019-03-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. 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-bess-vpls-multihoming-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-vpls-multihoming-03 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] Secdir last call review of draft-ietf-bess-bgp-vpls-control-flags-07
Reviewer: Watson Ladd Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This document fixes a corner case where some features were not being negotiated properly. It's quite clear and concise, and fixes what seems to be a real problem. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Question on symmetric IRB procedures in draft-ietf-bess-evpn-inter-subnet-forwarding
Hi authors, EVPN experts, Any feedback? Regards, Muthu On Wed, Mar 20, 2019 at 10:19 AM Muthu Arul Mozhi Perumal < muthu.a...@gmail.com> wrote: > draft-ietf-bess-evpn-inter-subnet-forwarding says the following in section > 3.2.2: > > >If the receiving PE receives this route with both the MAC-VRF and IP- >VRF route targets but the MAC/IP Advertisement route does not include >MPLS label2 field and if the receiving PE supports asymmetric IRB >mode, then the receiving PE installs the MAC address in the >corresponding MAC-VRF and association in the ARP table for >that tenant (identified by the corresponding IP-VRF route target). > > > Further below it says: > > >If the receiving PE receives this route with both the MAC-VRF and IP- >VRF route targets but the MAC/IP Advertisement route does not include >MPLS label2 field and if the receiving PE does not support either >asymmetric or symmetric IRB modes, then if it has the corresponding >MAC-VRF, it only imports the MAC address > > > How should "does not support either asymmetric or symmetric IRB" be > interpreted? Should it be interpreted as "supports neither asymmetric nor > symmetric"? Or should it be interpreted as "does not support one of them"? > > If it is the former, then the case where the receiving PE supports only > symmetric (but not asymmetric) IRB isn't described. It it is the later then > it includes the case where the receiving PE supports only asymmetric (but > not symmetric) IRB and what is described in that paragraph conflicts with > the first paragraph mentioned above. > > Regards, > Muthu > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
