Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Mar 2015 15:06:01 +0100

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:

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 31 Mar 2015 04:55:08 +0000

​

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 <[email-masked]> on behalf of Stewart Bryant <[email-masked]>
Sent: Monday, March 30, 2015 5:06 PM
To: Jiangyuanlong; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Yuanlong

=====================

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

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

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

     service with special restrictions: the Ethernet frames from a root may be
     E-Tree service may include multiple roots and multiple leaves. Although

     (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...'

===============

Looking at this text

617        2) else {

624                     else {

630                          }

632               }

638           }

Which I think makes it

                        else {

                             }

                  }

              }

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 31 Mar 2015 06:46:05 +0000

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:[email-masked]]
Sent: Tuesday, March 31, 2015 12:55 PM
To: Jiangyuanlong; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

​

My 2c,
Sasha
________________________________
From: Pals <[email-masked]<mailto:[email-masked]>> on behalf of Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 30, 2015 5:06 PM
To: Jiangyuanlong; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Yuanlong

=====================

     No issues found here.

     No issues found here.

  Miscellaneous warnings:

===============

Looking at this text

617    2) else {

624                 else {

630                      }

632           }

636           Mode to TRUE;

638       }

Which I think makes it

                    else {

                         and exit the process;

                         }

              }

              Mode to TRUE;

          }

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 31 Mar 2015 07:01:17 +0000

Yuanlong,
Lots of thanks for an extra-prompt response.
I agree that an E-Tree service may have no leaves in its transient states.
So I am OK with not adding new restrictions.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: Jiangyuanlong [mailto:[email-masked]]
Sent: Tuesday, March 31, 2015 9:46 AM
To: Alexander Vainshtein; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Hi Sasha,

Thanks,
Yuanlong

To: Jiangyuanlong; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

​

My 2c,
Sasha

Yuanlong

=====================

     No issues found here.

     No issues found here.

  Miscellaneous warnings:

===============

Looking at this text

617    2) else {

624                 else {

630                      }

632           }

636           Mode to TRUE;

638       }

Which I think makes it

                    else {

                         and exit the process;

                         }

              }

              Mode to TRUE;

          }

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 31 Mar 2015 07:49:01 +0000

Hi Stewart,

Thanks a lot for the prompt review☺
It seems the idnits tool used upon upload is not compatiable with the newest version (indeed, no issue was ever found in draft submission).
We have corrected those nits.

Regarding Line 614-617, we suggested to use:
   1) If either the root VLAN ID in the message not equals the local
      root VLAN ID or the leaf VLAN ID in the message not equals the
      local leaf VLAN ID then {

The text is somewhat lengthy but may be clearer. BGP setion is also revised to be consistent with this change.

Plese refer to the newest version:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-06

Any further comments are welcome.

Best regards,
Yuanlong

From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 30, 2015 10:06 PM
To: Jiangyuanlong; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pals] Shepherd review of draft-ietf-l2vpn-vpls-pe-etree

Yuanlong

=====================

     No issues found here.

     No issues found here.

  Miscellaneous warnings:

===============

Looking at this text

617    2) else {

624                 else {

630                      }

632           }

636           Mode to TRUE;

638       }

Which I think makes it

                    else {

                         and exit the process;

                         }

              }

              Mode to TRUE;

          }