Hi Sasha, I agree with you that 2119 language should be used in this paragraph.
Though normal E-Tree service usually consists of at least one root and at least two leaves, MEF 6.1 says [Page 16]:”An E-Tree service may have no leaves, for example, during times when leaf UNIs are being added or removed.” So we’d better add no more limitations to the texts. Thanks, Yuanlong From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] Sent: Tuesday, March 31, 2015 12:55 PM To: Jiangyuanlong; draft-ietf-l2vpn-vpls-pe-et...@tools.ietf.org; p...@ietf.org; stbry...@cisco.com Cc: l2vpn-cha...@tools.ietf.org; bess-cha...@tools.ietf.org; pals-cha...@tools.ietf.org; bess@ietf.org Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree Stewart, authors and all, One of the nits in the review mentions inconsistent use of "MUST not" in the text that defines what constitutes an E-Tree service. I have noticed that the same fragment also contains several cases of "may", and it is not clear to me whether it should be replaced by the 2119 "MAY" or not. After reading this fragment (as quoted in the review) I wonder whether an E-Tree service does not require at least one root and at least two leaves. From my POV if the second of these conditions is not met, the connectivity restrictions become meaningless, and if the first one is not met, the service would not pass any traffic at all. If these observations are correct, it makes sense to state these limitations explicitly using 2119 language (MUST include...). A apologize for inadvertently sending an earlier version of this text in response to a wrong message. My 2c, Sasha ________________________________ From: Pals <pals-boun...@ietf.org<mailto:pals-boun...@ietf.org>> on behalf of Stewart Bryant <stbry...@cisco.com<mailto:stbry...@cisco.com>> Sent: Monday, March 30, 2015 5:06 PM To: Jiangyuanlong; draft-ietf-l2vpn-vpls-pe-et...@tools.ietf.org<mailto:draft-ietf-l2vpn-vpls-pe-et...@tools.ietf.org>; p...@ietf.org<mailto:p...@ietf.org> Cc: l2vpn-cha...@tools.ietf.org<mailto:l2vpn-cha...@tools.ietf.org>; bess-cha...@tools.ietf.org<mailto:bess-cha...@tools.ietf.org>; pals-cha...@tools.ietf.org<mailto:pals-cha...@tools.ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree Yuanlong The text has the following nits mostly this is just minor editing but does need to be fixed. RFC 6136 can be made an informational ref ===================== tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt: tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(20): Line is too long: the offending characters are '.' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(227): Line is too long: the offending characters are '.' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(415): Line is too long: the offending characters are ',' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(579): Line is too long: the offending characters are 'e' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(582): Line is too long: the offending characters are 'N,' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(632): Line is too long: the offending characters are 'n' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(635): Line is too long: the offending characters are 'e' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(917): Line is too long: the offending characters are 'n' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(924): Line is too long: the offending characters are '.' tmp/draft-ietf-l2vpn-vpls-pe-etree-05.txt(1138): Line has weird spacing: '...) where any t...' Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Ethernet-Tree (E-Tree) service is defined in Metro Ethernet Forum (MEF) Technical Specification MEF 6.1 as a Rooted-Multipoint Ethernet Virtual Connection (EVC) service. It is a multipoint Ethernet service with special restrictions: the Ethernet frames from a root may be received by any other root or leaf, and the frames from a leaf may be received by any root, but MUST not be received by a leaf. Further, an E-Tree service may include multiple roots and multiple leaves. Although Virtual Private Multicast Service (VPMS) [VPMS] or Point-to-Multipoint (P2MP) multicast is a somewhat simplified version of this service, in fact, there is no exact corresponding terminology in IETF yet. -- The document date (February 26, 2015) is 32 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MEF4' is defined on line 872, but no explicit reference was found in the text '[MEF4] Metro Ethernet Forum, Metro Ethernet Network Architecture...' ** Downref: Normative reference to an Informational RFC: RFC 6136 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). =============== Looking at this text 614 1) if the root and leaf VLAN ID in the message match the local root 615 and leaf VLAN ID, then continue to 3); 617 2) else { 619 if the bit V is cleared, then { 621 if the PE is capable of VLAN mapping, then it MUST set 622 VLAN-Mapping-Mode to TRUE; 624 else { 626 A label release message with the error code "E-Tree 627 VLAN mapping not supported" is sent to the peer PE 628 and exit the process; 630 } 632 } 634 if the bit V is set, and the PE is capable of VLAN mapping, 635 then the PE with the minimum IP address MUST set VLAN-Mapping- 636 Mode to TRUE; 638 } 640 3) If the P bit is set, then: It might be clearer to apply De Morgan: Which I think makes it 1) if the root not equal local root or leaf VLAN ID not equal to leaf VLAN ID in the message match then if the bit V is cleared, then { if the PE is capable of VLAN mapping, then it MUST set VLAN-Mapping-Mode to TRUE; else { A label release message with the error code "E-Tree VLAN mapping not supported" is sent to the peer PE and exit the process; } } if the bit V is set, and the PE is capable of VLAN mapping, then the PE with the minimum IP address MUST set VLAN-Mapping- Mode to TRUE; } 2) If the P bit is set, then:
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
