Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Sasha,

Once more thank very much for your review and your comments. Please refer to my reply inline

From: Alexander Vainshtein <[e-mail]>
Date: Thursday, March 29, 2018 at 4:32 AM
To: "Bocci, Matthew (Nokia - GB)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Cisco Employee <[e-mail]>
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:

  1.  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).”


  1.  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).


  1.  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:

  1.  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.”


  1.  RT Constraint is mentioned in Section 3.1 without any references. I suggest to add an Informational reference to RFC 4684.
Done.


  1.  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.


  1.  Section 3.3.1:  It seems that the title includes some of the content.
Corrected.


  1.  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.


  1.  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.



  1.  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: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Bocci, Matthew (Nokia - GB) [mailto:[e-mail]]
Sent: Thursday, March 29, 2018 11:48 AM
To: Alexander Vainshtein <[e-mail]>; Ali Sajassi (sajassi) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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/

Regards

Matthew

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 29 March 2018 at 06:55
To: "Bocci, Matthew (Nokia - GB)" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, March 29, 2018 7:20:16 AM
To: Alexander Vainshtein; Bocci, Matthew (Nokia - GB)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 28, 2018 at 7:32 AM
To: "Bocci, Matthew (Nokia - GB)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
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: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: BESS [mailto:[e-mail]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, March 28, 2018 3:50 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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.
___________________________________________________________________________