Re: [bess] AD Review of draft-ietf-bess-dci-evpn-overlay-05
Hi Alvaro, I just fixed the two nits referred below, added a sentence requested by Anoop, and published rev 07. See my comments below. Please let us know if there is anything else to do. Thank you. Jorge From: Alvaro Retana <aretana.i...@gmail.com> Date: Friday, January 26, 2018 at 10:17 PM To: "draft-ietf-bess-dci-evpn-over...@ietf.org" <draft-ietf-bess-dci-evpn-over...@ietf.org>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com> Cc: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigour...@nokia.com>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org> Subject: Re: AD Review of draft-ietf-bess-dci-evpn-overlay-05 Jorge: Thanks for the update. I’m starting the IETF LC, but I need you to please fix the nits related to the references: == Missing Reference: 'RFC8174' is mentioned on line 125, but not defined [JORGE] fixed. thx -- No information found for draft-ietf-bess-evpn-vpls-integration - is the name correct? [JORGE] the correct reference should have been draft-ietf-bess-evpn-vpls-seamless-integ-00, however with the small change in the text (see rev 07 diff), and given it was an informative reference and expired, I don’t think we even need to refer to that draft, so I removed the reference. Thanks! Alvaro. On January 22, 2018 at 4:16:35 PM, Rabadan, Jorge (Nokia - US/Mountain View) (jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>) wrote: Hi Alvaro, Thank you very much for your detailed review. Revision 06 has just been uploaded. This rev addresses all your comments. Please see some responses in-line with [JORGE]. Thanks. Jorge From: Alvaro Retana <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>> Date: Thursday, January 18, 2018 at 5:08 PM To: "draft-ietf-bess-dci-evpn-over...@ietf.org<mailto:draft-ietf-bess-dci-evpn-over...@ietf.org>" <draft-ietf-bess-dci-evpn-over...@ietf.org<mailto:draft-ietf-bess-dci-evpn-over...@ietf.org>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>> Subject: AD Review of draft-ietf-bess-dci-evpn-overlay-05 Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent-To: <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, <senthil.sathap...@nokia.com<mailto:senthil.sathap...@nokia.com>>, <wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>, <saja...@cisco.com<mailto:saja...@cisco.com>>, <jdr...@juniper.net<mailto:jdr...@juniper.net>> Resent-Date: Thursday, January 18, 2018 at 5:08 PM Dear authors: I just finished reading this document. As with draft-ietf-bess-evpn-overlay, it seems to me that this document is better suited as an Applicability Statement [1] instead of a Technical Specification -- both would result in a Standards Track document. It is hard for me to clearly identify what this document is specifying, vs explaining how to use existing mechanisms (already specified elsewhere) to achieve the DCI. I don't want to dig too deep into this point, but it would be nice if you at least considered refocusing the text. [JORGE] While a good part of the document describes how different Technical Specifications can be applied to the DCI case, the document also describes new procedures or extensions of its normative Technical Specs. In particular, the new EVPN extensions are: • The Interconnect Ethernet Segment (I-ES), its definition and usage are different than the one in [RFC7432] • The use of the Unknown MAC route in I-ES • The processing of EVPN routes on Gateways with MAC-VRFs connecting EVPN-Overlay to EVPN-MPLS networks. I changed the abstract and the introduction to reflect that. I do have some more comments below. I'll wait for an updated draft before starting the IETF Last Call. Thanks! Alvaro. [1] https://tools.ietf.org/html/rfc2026#section-3.2 Major: M1. I don't feel too good about using Normative Language to describe the requirements (2.1 and 3.1) because the normative part of this document should be the solution itself, not the requirements (which the solution will then solve). As I read the requirements, with the Normative Language in them, there are questions that come up, which wouldn't be there if rfc2119 keywords were not used. [JORGE] OK. I changed sections 2.1 and 3.1 and removed Normative Language. M1.1. There's an important use of the words "supported" and "implemented", what do they mean from a Normative point of view
Re: [bess] AD Review of draft-ietf-bess-dci-evpn-overlay-05
Jorge: Thanks for the update. I’m starting the IETF LC, but I need you to please fix the nits related to the references: == Missing Reference: 'RFC8174' is mentioned on line 125, but not defined -- No information found for draft-ietf-bess-evpn-vpls-integration - is the name correct? Thanks! Alvaro. On January 22, 2018 at 4:16:35 PM, Rabadan, Jorge (Nokia - US/Mountain View) (jorge.raba...@nokia.com) wrote: Hi Alvaro, Thank you very much for your detailed review. Revision 06 has just been uploaded. This rev addresses all your comments. Please see some responses in-line with *[JORGE].* Thanks. Jorge *From: *Alvaro Retana <aretana.i...@gmail.com> *Date: *Thursday, January 18, 2018 at 5:08 PM *To: *"draft-ietf-bess-dci-evpn-over...@ietf.org" < draft-ietf-bess-dci-evpn-over...@ietf.org> *Cc: *"bess@ietf.org" <bess@ietf.org>, "bess-cha...@ietf.org" < bess-cha...@ietf.org>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" < martin.vigour...@nokia.com> *Subject: *AD Review of draft-ietf-bess-dci-evpn-overlay-05 *Resent-From: *<alias-boun...@ietf.org> *Resent-To: *<jorge.raba...@nokia.com>, <senthil.sathap...@nokia.com>, < wim.henderi...@nokia.com>, <saja...@cisco.com>, <jdr...@juniper.net> *Resent-Date: *Thursday, January 18, 2018 at 5:08 PM Dear authors: I just finished reading this document. As with draft-ietf-bess-evpn-overlay, it seems to me that this document is better suited as an Applicability Statement [1] instead of a Technical Specification -- both would result in a Standards Track document. It is hard for me to clearly identify what this document is specifying, vs explaining how to use existing mechanisms (already specified elsewhere) to achieve the DCI. I don't want to dig too deep into this point, but it would be nice if you at least considered refocusing the text. *[JORGE] While a good part of the document describes how different Technical Specifications can be applied to the DCI case, the document also describes new procedures or extensions of its normative Technical Specs. In particular, the new EVPN extensions are:* · *The Interconnect Ethernet Segment (I-ES), its definition and usage are different than the one in [RFC7432]* · *The use of the Unknown MAC route in I-ES* · *The processing of EVPN routes on Gateways with MAC-VRFs connecting EVPN-Overlay to EVPN-MPLS networks.* *I changed the abstract and the introduction to reflect that. * I do have some more comments below. I'll wait for an updated draft before starting the IETF Last Call. Thanks! Alvaro. [1] https://tools.ietf.org/html/rfc2026#section-3.2 Major: M1. I don't feel too good about using Normative Language to describe the requirements (2.1 and 3.1) because the normative part of this document should be the solution itself, not the requirements (which the solution will then solve). As I read the requirements, with the Normative Language in them, there are questions that come up, which wouldn't be there if rfc2119 keywords were not used. *[JORGE] OK. I changed sections 2.1 and 3.1 and removed Normative Language.* M1.1. There's an important use of the words "supported" and "implemented", what do they mean from a Normative point of view? Are you using them from the point of view of the operator implementing something in their network, or the solution (the software feature) including them? How do you Normatively enforce that? Some examples of their use are: "Per-service load balancing MUST be supported. Per-flow load balancing MAY be supported..." (2.1), "The following optimizations MAY be supported..." (2.1), "Multi-homing MUST be supported. Single-active multi-homing with per-service load balancing MUST be implemented. All-active multi-homing, i.e. per-flow load-balancing, SHOULD be implemented as long as the technology deployed in the WAN supports it" (3.1). In summary, I think that the requirements would be better served with non-rfc2119 language. *[JORGE] OK, fixed now.* M1.2. The use of "MUST be supported" doesn't stop when talking about the requirements: M1.2.1. In 2.4: "As already discussed, single-active multi-homing, i.e. per-service load-balancing multi-homing MUST be supported in this type of interconnect." Assuming you take off the Normative Language in 2.1, take out "as already discussed"... *[JORGE] removed.* M1.2.2. In 2.5: "The following features MAY be supported..." I'm assuming "MAY" is used here because the optimizations are optional; saying so would be better as some of the descriptions in the sub-sections include other Normative Language. *[JORGE] Changed to "The following GW features are optional and optimize the control plane and data plane in the DC."* M1.2.2. In 2.3 an o
Re: [bess] AD Review of draft-ietf-bess-dci-evpn-overlay-05
Hi Alvaro, Thank you very much for your detailed review. Revision 06 has just been uploaded. This rev addresses all your comments. Please see some responses in-line with [JORGE]. Thanks. Jorge From: Alvaro Retana <aretana.i...@gmail.com> Date: Thursday, January 18, 2018 at 5:08 PM To: "draft-ietf-bess-dci-evpn-over...@ietf.org" <draft-ietf-bess-dci-evpn-over...@ietf.org> Cc: "bess@ietf.org" <bess@ietf.org>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigour...@nokia.com> Subject: AD Review of draft-ietf-bess-dci-evpn-overlay-05 Resent-From: <alias-boun...@ietf.org> Resent-To: <jorge.raba...@nokia.com>, <senthil.sathap...@nokia.com>, <wim.henderi...@nokia.com>, <saja...@cisco.com>, <jdr...@juniper.net> Resent-Date: Thursday, January 18, 2018 at 5:08 PM Dear authors: I just finished reading this document. As with draft-ietf-bess-evpn-overlay, it seems to me that this document is better suited as an Applicability Statement [1] instead of a Technical Specification -- both would result in a Standards Track document. It is hard for me to clearly identify what this document is specifying, vs explaining how to use existing mechanisms (already specified elsewhere) to achieve the DCI. I don't want to dig too deep into this point, but it would be nice if you at least considered refocusing the text. [JORGE] While a good part of the document describes how different Technical Specifications can be applied to the DCI case, the document also describes new procedures or extensions of its normative Technical Specs. In particular, the new EVPN extensions are: · The Interconnect Ethernet Segment (I-ES), its definition and usage are different than the one in [RFC7432] · The use of the Unknown MAC route in I-ES · The processing of EVPN routes on Gateways with MAC-VRFs connecting EVPN-Overlay to EVPN-MPLS networks. I changed the abstract and the introduction to reflect that. I do have some more comments below. I'll wait for an updated draft before starting the IETF Last Call. Thanks! Alvaro. [1] https://tools.ietf.org/html/rfc2026#section-3.2 Major: M1. I don't feel too good about using Normative Language to describe the requirements (2.1 and 3.1) because the normative part of this document should be the solution itself, not the requirements (which the solution will then solve). As I read the requirements, with the Normative Language in them, there are questions that come up, which wouldn't be there if rfc2119 keywords were not used. [JORGE] OK. I changed sections 2.1 and 3.1 and removed Normative Language. M1.1. There's an important use of the words "supported" and "implemented", what do they mean from a Normative point of view? Are you using them from the point of view of the operator implementing something in their network, or the solution (the software feature) including them? How do you Normatively enforce that? Some examples of their use are: "Per-service load balancing MUST be supported. Per-flow load balancing MAY be supported..." (2.1), "The following optimizations MAY be supported..." (2.1), "Multi-homing MUST be supported. Single-active multi-homing with per-service load balancing MUST be implemented. All-active multi-homing, i.e. per-flow load-balancing, SHOULD be implemented as long as the technology deployed in the WAN supports it" (3.1). In summary, I think that the requirements would be better served with non-rfc2119 language. [JORGE] OK, fixed now. M1.2. The use of "MUST be supported" doesn't stop when talking about the requirements: M1.2.1. In 2.4: "As already discussed, single-active multi-homing, i.e. per-service load-balancing multi-homing MUST be supported in this type of interconnect." Assuming you take off the Normative Language in 2.1, take out "as already discussed"... [JORGE] removed. M1.2.2. In 2.5: "The following features MAY be supported..." I'm assuming "MAY" is used here because the optimizations are optional; saying so would be better as some of the descriptions in the sub-sections include other Normative Language. [JORGE] Changed to "The following GW features are optional and optimize the control plane and data plane in the DC." M1.2.2. In 2.3 an option exists...but in both cases "MUST be supported" is used. As I asked above, what does this mean from the enforcement of the Normative Language point of view? If we think about interoperability, then maybe a more prescriptive sentence would work better. Suggestion: s/the provisioning of the VCID for such PW MUST be supported on the MAC-VRF/the VCID MUST be provisioned… [JORGE] Done. M1.2.3. In 3.2.2./3.3.2<http://3.2.2./3.3.2>: "Single-active multi-homi
[bess] AD Review of draft-ietf-bess-dci-evpn-overlay-05
Dear authors: I just finished reading this document. As with draft-ietf-bess-evpn-overlay, it seems to me that this document is better suited as an Applicability Statement [1] instead of a Technical Specification -- both would result in a Standards Track document. It is hard for me to clearly identify what this document is specifying, vs explaining how to use existing mechanisms (already specified elsewhere) to achieve the DCI. I don't want to dig too deep into this point, but it would be nice if you at least considered refocusing the text. I do have some more comments below. I'll wait for an updated draft before starting the IETF Last Call. Thanks! Alvaro. [1] https://tools.ietf.org/html/rfc2026#section-3.2 Major: M1. I don't feel too good about using Normative Language to describe the requirements (2.1 and 3.1) because the normative part of this document should be the solution itself, not the requirements (which the solution will then solve). As I read the requirements, with the Normative Language in them, there are questions that come up, which wouldn't be there if rfc2119 keywords were not used. M1.1. There's an important use of the words "supported" and "implemented", what do they mean from a Normative point of view? Are you using them from the point of view of the operator implementing something in their network, or the solution (the software feature) including them? How do you Normatively enforce that? Some examples of their use are: "Per-service load balancing MUST be supported. Per-flow load balancing MAY be supported..." (2.1), "The following optimizations MAY be supported..." (2.1), "Multi-homing MUST be supported. Single-active multi-homing with per-service load balancing MUST be implemented. All-active multi-homing, i.e. per-flow load-balancing, SHOULD be implemented as long as the technology deployed in the WAN supports it" (3.1). In summary, I think that the requirements would be better served with non-rfc2119 language. M1.2. The use of "MUST be supported" doesn't stop when talking about the requirements: M1.2.1. In 2.4: "As already discussed, single-active multi-homing, i.e. per-service load-balancing multi-homing MUST be supported in this type of interconnect." Assuming you take off the Normative Language in 2.1, take out "as already discussed"... M1.2.2. In 2.5: "The following features MAY be supported..." I'm assuming "MAY" is used here because the optimizations are optional; saying so would be better as some of the descriptions in the sub-sections include other Normative Language. M1.2.2. In 2.3 an option exists...but in both cases "MUST be supported" is used. As I asked above, what does this mean from the enforcement of the Normative Language point of view? If we think about interoperability, then maybe a more prescriptive sentence would work better. Suggestion: s/the provisioning of the VCID for such PW MUST be supported on the MAC-VRF/the VCID MUST be provisioned... M1.2.3. In 3.2.2./3.3.2: "Single-active multi-homing MUST be supported on the GWs." ... M1.2.4. 3.4.3/3.5.2: "Single-active as well as all-active multi-homing MUST be supported." M2. From 2.5.3: "Individual AC/PW failures MAY be detected by OAM mechanisms." The "MAY" seems to just be stating a fact; s/MAY/may M2.1. The two "MAYs" in the bullets following the "for instance" seem out of place too. If the intent is to just list two possibilities (examples) then the "MAYs" should not be Normative. M3. Security Considerations. Please see my note above about thinking that this document is more appropriate to be an Applicability Statement (than a Technical Specification). The Security Considerations section basically directs the reader to existing work. I would like to see a statement (for the benefit of the security reviewers) along the lines of: "This document defines...as a result there are no new security considerations." Note that considering this document a Technical Specification by definition it means it adds something -- so please focus on that here. M4. References: The reference to draft-ietf-bess-evpn-overlay should be Normative. Minor: P1. The "Conventions and Terminology" (Section 5) should be moved to the front of the document. P2. Please add references to VPLS, EVPN, VXLAN, 802.1q/ag, etc, etc. on first mention. All these technologies are important in understanding the document, but only some are properly referenced later. Ideally, there would be a reference when a mayor technology is mentioned (specially the first time) and when other important features are mentioned and assumed -- for example: in "Even if optimized BGP techniques like RT-constraint are used..." it would be nice to put a reference to RT-constraint. It's all about the completeness of the document... P2.1. In 2.3: "the usual MPLS procedures between GW and WAN Edge router"; a reference here would be nice. P3. Please use the template in rfc8174, instead of the one in rfc2119. P4. In 3.4.1, I can't
