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 protected]]
Sent: Monday, March 30, 2015 10:06 PM
To: Jiangyuanlong; [email protected]; [email protected]
Cc: [email protected]; [email protected];
[email protected]; [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
