support -Lukas > Begin forwarded message: > > From: "Ali Sajassi (sajassi)" <saja...@cisco.com <mailto:saja...@cisco.com>> > Subject: Re: [bess] WG Last Call and IPR Poll for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > Date: April 2, 2018 at 7:13:44 PM PDT > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>>, "Bocci, Matthew (Nokia - GB)" > <matthew.bo...@nokia.com <mailto:matthew.bo...@nokia.com>> > Cc: "draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>" > <draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>>, > "bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>" <bess-cha...@ietf.org > <mailto:bess-cha...@ietf.org>>, "bess@ietf.org <mailto:bess@ietf.org>" > <bess@ietf.org <mailto:bess@ietf.org>> > > Hi Sasha, > > Once more thank very much for your review and your comments. Please refer to > my reply inline > > From: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>> > Date: Thursday, March 29, 2018 at 4:32 AM > To: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com > <mailto:matthew.bo...@nokia.com>> > Cc: "bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>" > <bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>>, > "draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>" > <draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>>, "bess@ietf.org > <mailto:bess@ietf.org>" <bess@ietf.org <mailto:bess@ietf.org>>, Cisco > Employee <saja...@cisco.com <mailto:saja...@cisco.com>> > Subject: RE: WG Last Call and IPR Poll for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > > Hi all, > Please see below some technical and editorial comments/question on the draft. > > Technical: > Section 3 mentions that integration between VPLS and EVPN is “possible (but > cumbersome)” even if the brownfield VPLS service instance has been set up > without BGP-based auto-discovery. I wonder if such integration is possible > even if the VPLS PEs do not support BGP-based VPLS auto-discovery at all. > (Note that Section 3.1 says that the VPLS PEs “advertise the BGP VPLS AD > route”) > Such integration is possible but cumbersome. So, I added an explanation to > the end of the sentence describing why it is cumbersome: > “In order to support seamless integration with (PBB-)VPLS PEs, this document > requires that (PBB-)VPLS PEs support VPLS AD per [RFC6074] and (PBB-)EVPN PEs > support both BGP EVPN routes per [RFC7432] and VPLS BGP-based A-D per > [RFC6074]. All the logic for this seamless integration SHALL reside on the > (PBB-)EVPN PEs. However, if a VPLS instance is setup without the use of > BGP-based A-D, it is still possible (but cumbersome) for (PBB-)EVPN PEs to > integrate into that VPLS instance by manually configuring the target VPLS PE > addresses for each VPLS instance on each (PBB-)EVPN PE (i.e., the integration > is no longer seamless).” > > In Section 3.1, the draft says that, if the operator uses the same RT for > VPLS AD routes and EVPN routes, “when a (PBB-)VPLS PE receives the EVPN > Inclusive Multicast route, it will ignore it on the basis that it belongs to > an unknown SAFI”. This statement raises two comments: > Should not “will” here be “MUST”? > I think both are correct but changed it to “MUST” to make it stronger. > > What if SAFI used for the EVPN Inclusive MC route is known to the MP-BGP > instance in the VPLS PE (e.g., because some EVPN instance with MAC-VRF in > this PE has been already set)? I assume that the EVPN Inclusive MC route > still MUST be ignored, but the basis for that would be that it is not > understood by the VSI that represents the VPLS instance in this PE > The VPLS PEs don’t support EVPN SAFI. If they do, then they are called EVPN > PEs. In other words, only EVPN PEs are bi-lingual (can speak both EVPN and > VPLS languages). > > The text in Section 4.2.1 says that if, following MAC move from an EVPN PE to > a VPLS PE, it initiates BUM traffic, this traffic is flooded to both VPLS and > EVPN PEs and “the receiving PEs update their MAC tables (VSI or MAC-VRF)”. > However, Section 3.2 says that MAC addresses received by the EVPN PE via PWs > from VPLS PEs are “not injected into (PBB-)EVPN MAC-VRF tables but rather > they are injected into their corresponding (PBB-)VPLS VSI table”. These two > statements look mutually contradictory to me. (See also my editorial comment > about having both MAC-VRF and VSI MAC table in the EVPN PE). > In general, the MAC addresses learned over PWs should be injected into the > MAC-VRF but depending on whether the PW is access-facing or core-facing, it > will or will not be advertised in control-plane. So, I updated the paragraph > in section 3.2 to the following: > “When the (PBB-)EVPN PE receives traffic over the pseudowires, it learns the > associated MAC addresses in the data-plane. The MAC addresses learned over > PWs are injected into (PBB-)EVPN MAC-VRF table. For seamless integration > between (PBB-)EVPN and (PBB-)VPLS PEs, since the core-facing PWs belongs to > the same split-horizon group as the core-facing MP2P EVPN service tunnels, > then the MAC addresses learned and associated to the PWs will NOT be > advertised in the control plane to any remote (PBB-)EVPN PEs. This is because > every (PBB-)EVPN PE can send and receive traffic directly to/from every > (PBB-)VPLS PE belonging to the same VPN instance.” > > Editorial: > Section 2, item 6 states that “The solution SHOULD support All-Active > redundancy mode of multi-homed networks and multi-homed devices for > (PBB-)EVPN PEs. In case of All-Active redundancy mode, the participant VPN > instances SHOULD be confined to (PBB-)EVPN PEs only”.. My reading of this is > that All-Active redundancy mode is not compatible with seamless integration > of VPLS and EVPN in the same service (hardly any surprises here). If my > understanding is correct, All-Active redundancy mode seems to be out of scope > for this draft. > Your understanding is correct. Rephrased the sentence to: > “6. The support of All-Active redundancy mode across both (PBB-)EVPN PEs and > (PBB-)VPLS PEs is outside the scope of this document.” > > RT Constraint is mentioned in Section 3.1 without any references. I suggest > to add an Informational reference to RFC 4684. > Done. > > The text about MAC learning from PWs in Section 3.2 seems to suggest that the > service instance in an (PBB-)EVPN PE is represented by both a dedicated > MAC-VRF and a dedicated VSI. However, this issue is not explicitly presented > anywhere in the draft. Some text and diagrams would be most welcome IMHO > To remove any ambiguity, VSI is now limited to (PBB-)VPLS PEs only – i.e., > (PBB-)EVPN PEs only use MAC-VRF. > > Section 3.3.1: It seems that the title includes some of the content. > Corrected. > > Section 3.3.2 has a very long title and no content at all. (For comparison, > parallel sections 4.3.2 and 5.3.2 have short titles and some content each). > Corrected. > > In section 4.2.1, a MAC address that moves from an EVPN PE to a VPLS PE is > not qualified, but a MAC address that moved from a VPLS PE to an EVPN PE is > referred to as a “host MAC address”. I suggest to align the terminology > between these two cases. > Now Using “C-MAC” for both of them. > > > Abbreviation MHN and MHD appear in Section 6 without any expansion or > definition. (Looking them up in the Web did not yield anything suitable > either). > Added to terminology section. > > > Hopefully, these comments will be useful, and the authors’ feedback would be > highly appreciated. > Your feedbacks are great! Thank you for taking the time in reading the draft > thoroughly and giving these feedbacks. > > Regards, > Ali > > > Regards, and lots ofthanks in advance, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com> > > From: Bocci, Matthew (Nokia - GB) [mailto:matthew.bo...@nokia.com > <mailto:matthew.bo...@nokia.com>] > Sent: Thursday, March 29, 2018 11:48 AM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>>; Ali Sajassi (sajassi) > <saja...@cisco.com <mailto:saja...@cisco.com>> > Cc: bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>; > draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>; bess@ietf.org > <mailto:bess@ietf.org> > Subject: Re: WG Last Call and IPR Poll for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > > Thanks for the quick turnaround. > > Folks, please focus any further review and comments on the new v02 of the > draft: > > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ > <https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/> > > Regards > > Matthew > > From: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>> > Date: Thursday, 29 March 2018 at 06:55 > To: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com > <mailto:matthew.bo...@nokia.com>>, "Ali Sajassi (sajassi)" <saja...@cisco.com > <mailto:saja...@cisco.com>> > Cc: "bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>" > <bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>>, > "draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>" > <draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>>, "bess@ietf.org > <mailto:bess@ietf.org>" <bess@ietf.org <mailto:bess@ietf.org>> > Subject: Re: WG Last Call and IPR Poll for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > > Ali and all, > I have looked up the -02 revision of the draft, and the texr looks much more > mature now. > > I will read it again and send technical comments (if any) next week as well > as my position regarding its support. > > Thumb typed by Sasha Vainshtein > > From: Ali Sajassi (sajassi) <saja...@cisco.com <mailto:saja...@cisco.com>> > Sent: Thursday, March 29, 2018 7:20:16 AM > To: Alexander Vainshtein; Bocci, Matthew (Nokia - GB) > Cc: bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>; > draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>; bess@ietf.org > <mailto:bess@ietf.org> > Subject: Re: WG Last Call and IPR Poll for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > > Hi Sasha, > > Thanks for your comments. I took care of them all in rev02 of the document > that I just posted. > > Cheers, > Ali > > From: Alexander Vainshtein <alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com>> > Date: Wednesday, March 28, 2018 at 7:32 AM > To: "Bocci, Matthew (Nokia - GB)" <matthew.bo...@nokia.com > <mailto:matthew.bo...@nokia.com>> > Cc: "bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>" > <bess-cha...@ietf.org <mailto:bess-cha...@ietf.org>>, > "draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>" > <draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>>, "bess@ietf.org > <mailto:bess@ietf.org>" <bess@ietf.org <mailto:bess@ietf.org>> > Subject: RE: WG Last Call and IPR Poll for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > Resent-From: <alias-boun...@ietf.org <mailto:alias-boun...@ietf.org>> > Resent-To: Cisco Employee <saja...@cisco.com <mailto:saja...@cisco.com>>, > <ssa...@cisco.com <mailto:ssa...@cisco.com>>, <nick.delre...@verizon.com > <mailto:nick.delre...@verizon.com>>, <jorge.raba...@nokia.com > <mailto:jorge.raba...@nokia.com>> > Resent-Date: Wednesday, March 28, 2018 at 7:32 AM > > Matthew, and all, <> > I’ve looked up the -01 version of the draft and I have found 5 references to > a future revision of the document (all dealing with either LSM or MAC > Mobility handling). > These references are in the following sections: > 3.3.2 (LSM) > 4.2 (MAC mobility) > 4.3.2 (LSM) > 5.2 (MAC mobility) > 5.3.2 (LSM) > > BTW, the abbreviation “LSM” is not expanded in the document, and I admit that > do not know what it means in the context of this draft. > > I wonder whether the document in this state is ready for the WG LC because, > to me, these references indicate that the authors do not consider their work > as complete. > > What, if anything, did I miss? > > Regards, and lots of thanks in advance, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > <mailto:alexander.vainsht...@ecitele.com> > > From: BESS [mailto:bess-boun...@ietf.org <mailto:bess-boun...@ietf.org>] On > Behalf Of Bocci, Matthew (Nokia - GB) > Sent: Wednesday, March 28, 2018 3:50 PM > To: draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org > <mailto:draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org>; bess@ietf.org > <mailto:bess@ietf.org> > Cc: bess-cha...@ietf.org <mailto:bess-cha...@ietf.org> > Subject: [bess] WG Last Call and IPR Poll for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > > This email begins a two-week working group last call for > draft-ietf-bess-evpn-vpls-seamless-integ-01.txt > > Please review the draft and post any comments to the BESS working group list. > > We are also polling for knowledge of any undisclosed IPR that applies to this > Document, to ensure that IPR has been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as an author or a contributor of this document, please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR, copying the BESS mailing list. The document won't > progress without answers from all the authors and contributors. > Currently there is one IPR declaration against this document. > If you are not listed as an author or a contributor, then please explicitly > respond only if you are aware of any IPR that has not yet been disclosed in > conformance with IETF rules. > We are also polling for any existing implementations. > The working group last call closes on Wednesday 11th April. > > Regards, > Matthew and Stéphane > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ___________________________________________________________________________ > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ___________________________________________________________________________ > > > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ___________________________________________________________________________ > > _______________________________________________ > BESS mailing list > BESS@ietf.org <mailto:BESS@ietf.org> > https://www.ietf.org/mailman/listinfo/bess > <https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
