Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06
Hi Jari, I have fixed the nits identified by Ben and upload the new version (08). Thanks, Lucy -Original Message- From: Jari Arkko [mailto:jari.ar...@piuha.net] Sent: Wednesday, August 06, 2014 6:00 PM To: Lucy yong Cc: Ben Campbell; gen-art@ietf.org Team (gen-art@ietf.org); i...@ietf.org list; draft-ietf-l2vpn-etree-frwk@tools.ietf.org Subject: Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06 Thanks for the review, Ben. Looks like the substantive issues have been resolved and the editorial ones are on their way to be fixed. (Thanks Lucy!) Jari ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06
Hi Ben, See my reply inline w/ [lucy] I apologize for the late response. I somehow missed your mail when it came in originally. Comments inline. I've deleted sections where I don't have further comment. [Lucy] No problem. Thanks! Ben. On Jul 15, 2014, at 3:18 PM, Lucy yong lucy.y...@huawei.com wrote: [...] -- I suggest removing the 2119 language. Ignoring the general controversies over whether informational RFCs should use 2119 language, I don't think it fits for _this_ draft. In particular, all the small number of normative language instances seems to be either statements of fact or restatements of requirements that are defined elsewhere. These would all be better served with descriptive language. [Lucy] OK. I will change as you suggested. The 2119 language has been removed, but you still have a reference to RFC 2119 in the reference section. [Lucy] Sorry. Forget to remove that. We can fix that. [...] 5.2 seems like the same gap as discussed in 5.1, just from a perspective of CA role vs forwarding constraint. Handing around constraints vs roles seem more like solution questions than requirements or architecture questions. [Lucy] One is assigned the role at AC that impacts the forwarding; another is to convey or advertise the assigned AC role. Since these may relate to different techniques used in L2VPN, it is good to keep them in different sections. Okay [Lucy] good. [...] Nits/editorial comments: -- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One role is Root and another is Leaf. Are these the same usages as defined in this document? If so, it might be helpful to attribute these in the terminology section. [Lucy] We define Root AC and Leaf AC in terminology and use them in the framework. Will that be OK? My comment was that _this_ document defines the roles, but also says that MEF defines them. If those definitions are the same, then it would useful for the definitions in this draft to mention that the usage is the same as defined by MEF, or say in section 2.2. that MEF defines these terms the same way as this draft. [Lucy] Agree. We can clarify that the AC role definition in this doc is the same as the OVC EP role definition in MEF. (OVC EP: Operator virtual connection end point). Thanks, Lucy [...] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06
Thanks for the review, Ben. Looks like the substantive issues have been resolved and the editorial ones are on their way to be fixed. (Thanks Lucy!) Jari signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06
Hi Lucy, I apologize for the late response. I somehow missed your mail when it came in originally. Comments inline. I've deleted sections where I don't have further comment. Thanks! Ben. On Jul 15, 2014, at 3:18 PM, Lucy yong lucy.y...@huawei.com wrote: [...] -- I suggest removing the 2119 language. Ignoring the general controversies over whether informational RFCs should use 2119 language, I don't think it fits for _this_ draft. In particular, all the small number of normative language instances seems to be either statements of fact or restatements of requirements that are defined elsewhere. These would all be better served with descriptive language. [Lucy] OK. I will change as you suggested. The 2119 language has been removed, but you still have a reference to RFC 2119 in the reference section. [...] 5.2 seems like the same gap as discussed in 5.1, just from a perspective of CA role vs forwarding constraint. Handing around constraints vs roles seem more like solution questions than requirements or architecture questions. [Lucy] One is assigned the role at AC that impacts the forwarding; another is to convey or advertise the assigned AC role. Since these may relate to different techniques used in L2VPN, it is good to keep them in different sections. Okay [...] Nits/editorial comments: -- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One role is Root and another is Leaf. Are these the same usages as defined in this document? If so, it might be helpful to attribute these in the terminology section. [Lucy] We define Root AC and Leaf AC in terminology and use them in the framework. Will that be OK? My comment was that _this_ document defines the roles, but also says that MEF defines them. If those definitions are the same, then it would useful for the definitions in this draft to mention that the usage is the same as defined by MEF, or say in section 2.2. that MEF defines these terms the same way as this draft. [...] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06
Hi Ben, Thank you for the review and suggestions. Please see inline below w/ [Lucy] -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Monday, July 14, 2014 5:40 PM To: draft-ietf-l2vpn-etree-frwk@tools.ietf.org Cc: gen-art@ietf.org Team (gen-art@ietf.org); i...@ietf.org list Subject: Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l2vpn-etree-frwk-06 Reviewer: Ben Campbell Review Date: 2014-07-14 IETF LC End Date: 2014-07-15 Summary: This draft is almost ready for publication as an RFC, but I have a few minor issues and editorial comments that may be worth consideration prior to publication. Major issues: None Minor issues: -- I suggest removing the 2119 language. Ignoring the general controversies over whether informational RFCs should use 2119 language, I don't think it fits for _this_ draft. In particular, all the small number of normative language instances seems to be either statements of fact or restatements of requirements that are defined elsewhere. These would all be better served with descriptive language. [Lucy] OK. I will change as you suggested. -- Section 4, paragraph after Table 1: If direct Layer 2 Leaf-to-Leaf communication needs to be prohibited, E-Tree should be used. That sounds more like advocacy than architecture/framework. Do you mean to suggest that other potential solutions (if any) should not be used, or that E-Tree is somehow the best solution? Or did you mean to say E-Trees are appropriate for whenever...? [Lucy] OK, I will change the wording. -- Similarly, 2 paragraphs down: An E-Tree service can meet these use case requirements. That also sounds like advocacy. This draft doesn't seem to do a requirements analysis for those use cases, beyond an assumption that they need inter-leaf isolation at Layer 2. Something to the effect of E-Trees can meet the common requirement to avoid the exchange of frames between Leaf CAs. would be more appropriate. [Lucy] OK. Will fix that. -- 5.1 and 5.2: 5.2 seems like the same gap as discussed in 5.1, just from a perspective of CA role vs forwarding constraint. Handing around constraints vs roles seem more like solution questions than requirements or architecture questions. [Lucy] One is assigned the role at AC that impacts the forwarding; another is to convey or advertise the assigned AC role. Since these may relate to different techniques used in L2VPN, it is good to keep them in different sections. -- 5.3, First sentence: The first sentence seems like yet a further restatement of the issue from 5.1 and 5.2. (The rest of the section seems reasonably distinct from the others.) [Lucy] Yeah. I will remove the first sentence. -- Security Considerations: The security considerations mostly say that e-trees have to act like e-trees. I think there is room for more discussion. Are the e-tree rules sufficient for scenarios where inter-leaf isolation is critical for security reasons? Does it remove needs for higher layer protections? (I hope not.) The guidance to use IPSec if additional security is required is not entirely satisfying here--how would an higher layer protocol know whether or not it had a fully protected path? [Lucy] For the first point, yes, E-tree can be used to inter-leaf isolation for the security reason. However higher layer does not have any knowledge of AC role at lower layer, I don't think that it can rely on the lower layer for the protection. I'll add that clarification. For the second point, to clarify, E-Tree is an L2 service that is implemented over MPLS network, not IP underlying. If an operator chooses running the mpls over IP network, such security concern need to be addressed there. This has no change on the security that the mpls provides. Are there trust issues between PEs? Can one PE assume that another will enforce the leave/root constraints? Can it trust that the other PE has the same idea of what should be a leaf vs root? Is there a need for one PE to determine if another supports E-Trees at all? [Lucy] A MPLS domain is operated by an operator. Thus, there is trust between PEs. I will explicitly make that clear in this section. Nits/editorial comments: -- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One role is Root and another is Leaf. Are these the same usages as defined in this document? If so, it might be helpful to attribute these in the terminology section. [Lucy] We define Root AC and Leaf AC in terminology and use them in the framework. Will that be OK? -- 2.3, 2nd paragraph: ... distinct differentiation for multicast groups in one VPN. I suggest ... distinct differentiation among multicast groups in the same VPN
[Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l2vpn-etree-frwk-06 Reviewer: Ben Campbell Review Date: 2014-07-14 IETF LC End Date: 2014-07-15 Summary: This draft is almost ready for publication as an RFC, but I have a few minor issues and editorial comments that may be worth consideration prior to publication. Major issues: None Minor issues: -- I suggest removing the 2119 language. Ignoring the general controversies over whether informational RFCs should use 2119 language, I don't think it fits for _this_ draft. In particular, all the small number of normative language instances seems to be either statements of fact or restatements of requirements that are defined elsewhere. These would all be better served with descriptive language. -- Section 4, paragraph after Table 1: If direct Layer 2 Leaf-to-Leaf communication needs to be prohibited, E-Tree should be used. That sounds more like advocacy than architecture/framework. Do you mean to suggest that other potential solutions (if any) should not be used, or that E-Tree is somehow the best solution? Or did you mean to say E-Trees are appropriate for whenever...? -- Similarly, 2 paragraphs down: An E-Tree service can meet these use case requirements. That also sounds like advocacy. This draft doesn't seem to do a requirements analysis for those use cases, beyond an assumption that they need inter-leaf isolation at Layer 2. Something to the effect of E-Trees can meet the common requirement to avoid the exchange of frames between Leaf CAs. would be more appropriate. -- 5.1 and 5.2: 5.2 seems like the same gap as discussed in 5.1, just from a perspective of CA role vs forwarding constraint. Handing around constraints vs roles seem more like solution questions than requirements or architecture questions. -- 5.3, First sentence: The first sentence seems like yet a further restatement of the issue from 5.1 and 5.2. (The rest of the section seems reasonably distinct from the others.) -- Security Considerations: The security considerations mostly say that e-trees have to act like e-trees. I think there is room for more discussion. Are the e-tree rules sufficient for scenarios where inter-leaf isolation is critical for security reasons? Does it remove needs for higher layer protections? (I hope not.) The guidance to use IPSec if additional security is required is not entirely satisfying here--how would an higher layer protocol know whether or not it had a fully protected path? Are there trust issues between PEs? Can one PE assume that another will enforce the leave/root constraints? Can it trust that the other PE has the same idea of what should be a leaf vs root? Is there a need for one PE to determine if another supports E-Trees at all? Nits/editorial comments: -- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One role is Root and another is Leaf. Are these the same usages as defined in this document? If so, it might be helpful to attribute these in the terminology section. -- 2.3, 2nd paragraph: ... distinct differentiation for multicast groups in one VPN. I suggest ... distinct differentiation among multicast groups in the same VPN. -- 3: Figure 1 The figure is two pages from the paragraph that describes it. I suggest moving Figure 1 to either before or after the first paragraph in the section. -- 3, first paragraph This implies that an Ethernet frame from CE01, CE02, etc will be treated as a frame originated from a Root AC; a frame from CE03, CE04, etc will be treated as a frame originated from a Leaf AC. Treated by what? (Consider restating in active voice). -- 3, last paragraph before Figure 1: A VSI on a PE corresponds to an E-Tree instance ... This can be read to imply a 1-to-1 cardinality between A VSI on a PE and an E-Tree instance. I don't think that is intended. Also, is an E-Tree instance the same thing as and E-Tree service instance, as mentioned elsewhere? -- Section 4, paragraph after Table 1: Can you provide a reference and/or expansion for LTE X2? (I think LTE may be on the well-known abbreviation list, but I'm not sure about X2). -- Section 4, last paragraph: Unless you mean to say that broadcast video is a significant driver for this work, this paragraph seems off topic. -- Section 5 and subsections Section 5 needs additional proof reading for missing articles and singular/plural mismatches. -- Normative References: The two IEEE references seem more like informative rather than normative ones. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
