RE: [L1vpn] Chair review of draft-ietf-l1vpn-bgp-auto-discovery-02.txt

["Hamid Ould-Brahim" <[e-mail]>]

Hi Adrian, 

We will revise this draft and fix all the id nits.
Thanks.
Hamid. 

> 
> I think that this I-D is in a bit of a state.
> Lots of editorial nits that need to be tidied up.
> 
> Thanks,
> Adrian
> ===
> >From idnits (http://tools.ietf.org/tools/idnits/)
> 
>   Checking boilerplate required by RFC 3978 and 3979, updated 
> by RFC 4748:
>   
> --------------------------------------------------------------
> --------------
> 
>      No issues found here.
> 
>   Checking nits according to 
> http://www.ietf.org/ietf/1id-guidelines.txt:
>   
> --------------------------------------------------------------
> --------------
> 
>   ** Missing document type: Expected "INTERNET-DRAFT" in the 
> upper left hand
>      corner of the first page
> 
>   == No 'Intended status' indicated for this document; 
> assuming Proposed
>      Standard
> 
>   == It seems as if not all pages are separated by form feeds 
> - found 0 form
>      feeds but 9 pages
> 
> 
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>   
> --------------------------------------------------------------
> --------------
> 
>   ** The document seems to lack separate sections for 
> Informative/Normative
>      References.  All references will be assumed normative 
> when checking for
>      downward references.
> 
>   ** There are 7 instances of too long lines in the document, 
> the longest one
>      being 2 characters in excess of 72.
> 
> 
>   Miscellaneous warnings:
>   
> --------------------------------------------------------------
> --------------
> 
>      No issues found here.
> 
>   Checking references for intended status: Proposed Standard
>   
> --------------------------------------------------------------
> --------------
> 
>      (See RFC 3967 for information about using normative references to
>      lower-maturity documents in RFCs)
> 
>   == Missing Reference: 'RFC2858' is mentioned on line 171, 
> but not defined
> 
>   ** Obsolete undefined reference: RFC 2858 (Obsoleted by RFC 4760)
> 
>   == Unused Reference: 'GVPN' is defined on line 369, but no explicit
>      reference was found in the text
> 
>   == Unused Reference: 'BGP-MP' is defined on line 376, but 
> no explicit
>      reference was found in the text
> 
>   == Unused Reference: 'L1VPN-FRMK' is defined on line 390, 
> but no explicit
>      reference was found in the text
> 
>   == Outdated reference: A later version (-09) exists of
>      draft-ietf-l3vpn-bgpvpn-auto-05
> 
>   ** Downref: Normative reference to an Informational draft:
>      draft-ietf-l3vpn-bgpvpn-auto (ref. 'BGP-VPN-AUTODISCOVERY')
> 
>   == Outdated reference: A later version (-03) exists of
>      draft-fedyk-bgp-te-attribute-01
> 
>   -- Possible downref: Normative reference to a draft: ref.
>      'BGP-TE-ATTRIBUTE'  (No intended status found in state file of
>      draft-fedyk-bgp-te-attribute)
> 
>   -- Possible downref: Non-RFC (?) normative reference: ref. 'GVPN'
> 
>   == Outdated reference: draft-ietf-idr-bgp-ext-communities has been
>      published as RFC 4360
> 
>   ** Obsolete normative reference: RFC 2283 (ref. 'BGP-MP') 
> (Obsoleted by 
> RFC
>      2858)
> 
>   -- Possible downref: Normative reference to a draft: ref. 
> 'BGP-ORF'  (No
>      intended status found in state file of 
> draft-ietf-idr-route-filter)
> 
>   == Outdated reference: draft-ietf-l3vpn-rt-constrain has 
> been published as
>      RFC 4684
> 
>   == Outdated reference: draft-ietf-l1vpn-framework has been 
> published as 
> RFC
>      4847
> 
>   ** Downref: Normative reference to an Informational draft:
>      draft-ietf-l1vpn-framework (ref. 'L1VPN-FRMK')
> 
> 
>      Summary: 7 errors (**), 11 warnings (==), 3 comments (--).
> 
>      Run idnits with the --verbose option for more detailed 
> information 
> about
>      the items above.
> ===
> Working group reference on top line should read "Network 
> Working Group"
> ===
> Front page names should be "H. Ould-Brahim", "D. Fedyk" and 
> "Y. Rekhter"
> ===
> Whole document needs to leftshift five spaces
> ===
> Intended status.
> It seems to be that this is a protocol extension definition 
> for real-time 
> use. So I would expect to see this marked as Standards Track. 
> If that is the 
> case, I would expect you to include the boilerplate for RFC 
> 2119 language, 
> and I would expect you to use that language when defining the 
> procedures. 
> Also, in section 5, there are is lower case "should": how is 
> that to be 
> interpreted?
> ===
> Page footings...
> "     Ould-Brahim, Fedyk, Rekhter      June 2007            [Page 1] "
> or
> "     Ould-Brahim et al.          June 2007                   
>  [Page 2] "
> ?
> ===
> Please use page throws, they help people who don't read on line
> ===
> Please replace "draft" with "document" or "memo" in the text, 
> throughout. 
> This will be published as an RFC, at which point it will not 
> be a draft.
> ===
> Please replace "l1vpn" with "L1VPN" throughout.
> ===
> Please avoid the use of Microsoft smart quotes and 
> apostrophes. These are 
> showing up as "?" throughout the I-D.
> ===
> Abstract
> s/for layer-1 VPNs/for Layer-1 VPNs (L1VPNs)/
> s/CEs member/CE members/
> s/objective of/objective of a/
> s/support "single-/support the "single-/
> ===
> Abstract
> "That information is necessary for completing the signaling phase."
> The signaling phase of what?
> ===
> Changes from previous version section should either be marked 
> for the RFC 
> Editor to remove, or should be deleted now.
> ===
> Section 1.
> s/for layer-1 VPNs/for Layer-1 VPNs (L1VPNs)/
> s/CEs member/CE members/
> s/objective of/objective of a/
> s/support "single-/support the "single-/
> s/having a PE advertises/having a PE advertize/
> s/during signaling phase./during the signaling phase./
> ===
> Section 1
> "That information is necessary for completing the signaling phase."
> The signaling phase of what? (twice in this section!)
> ===
> Section 1
>  "The auto-discovery mechanism proceeds by having a PE advertises
>    to other PEs, at a minimum, its own IP address and the list of
>    <private address, provider address> tuples local to that PE. "
> I think this is sparse on explanation for an introduction 
> section. You need 
> to give a little background on the L1VPN for this tuple to 
> make any sense.
> ===
> Figure 1.
> It is great to have a figure in the introduction, but the 
> figure needs some 
> explanatory text!
> You need at least to describe what we see and define the acronyms.
> Note that there is a formatting error around VPN-B PIT in the 
> left hand PE.
> ===
> Section 1
>   "This version of the draft focuses on describing an auto-
>    discovery mechanism for the basic mode only. Details for the
>    enhanced mode will be described in future revised version of
>    this draft."
> You need to give references for the modes.
> You need to drop "this version".
> "Focuses" is wrong, since this is all that the I-D does.
> How about:
>   "[RFC4847] describes two modes of operation for a L1VPN: 
> the basic mode 
> and the enhanced mode. This document describes an 
> auto-discovery mechanism 
> for the basic mode only."
> ===
> Section 2
> s/may consists/may consist/
> s/a PE has as well an/a PE also has an/
> s/within that provider network/within the provider network/
> s/used for CPIs, PPIs/used for CPIs or PPIs/
> ===
> Section 2
> OLD
>   A PE maintains for each l1vpn configured on that PE a port
>   information tables (PIT) associated with each l1vpn that has at
>   least one port configured on a PE.
> NEW
>    For each L1VPN that has at least one port configured
>    on a PE, the PE maintains a port information table (PIT).
> ===
> Section 2
> s/may as well/may also/
> ===
> Section 2
> OLD
>    A PIT on a given PE is populated from two sources: the
>    information related to the CEs? ports attached to the ports on
>    that PE (this information could be optionally received from the
>    CEs), and the information received from other PEs through the
>    auto-discovery mechanism. We?ll refer to the former as the
>    "local" information, and to the latter as the "remote"
>    information.
> NEW
>     A PIT on a given PE is populated with two types of information.
>     - Information related to the CEs' ports attached to the ports on
>       the PE. This information could be locally configured at the PE
>       or could be received from the CEs)
>     - Information received from other PEs through the auto-
>       discovery mechanism.
>     We refer to the former as local information, and to the latter as
>      remote information.
> ===
> Section 2
> You work seems to depend on [BGP-VPN-AUTODISCOVERY]
> But even version 09 of this I-D seems to have disappeared.
> If this L1VPN work has overtaken the L2/3 VPN work then we 
> have to do some 
> juggling or delay this work.
> If the L2/3 work has been abandoned, then you need to move 
> some text into 
> this I-D.
> Please clarify.
> ===
> Section 2 bottom of page 3
> Twice in the paragraph you use the passive voice when 
> describing the PIT by 
> saying "is configured".
> Can you clarify if this is operator action, or implementation 
> behavior 
> triggered by protocol action.
> ===
> Section 2
> s/routes that have at least of these Communities./routes that 
> have at least 
> one of these Communities./
> ===
> Section 3
> s/Extensions BGP/Extensions to BGP/
> /a new a new/a new/
> ===
> Section 3 page 5
> PPI field and CPI field definitions.
> Missing close bracket
> ===
> Section 3
> s/whose value indicates address/whose value indicates the address/
> s/CPI (variable):/CPI field:/
> ===
> Section 3
>   "If the value of the Length of the Next Hop field is 4, then the
>    Next Hop contains an IPv4 address.  If this value is 16, then
>    the Next Hop contains an IPv6 address."
> Please give some reference to where the Next Hop field is 
> found (e.g., the 
> Next Hop field of the MP_REACH_NLRI attribute).
> ===
> Section 4
>   "In addition to reachability information, the auto-discovery
>    mechanism may carry Traffic Engineering information that will be
>    used for signaling purposes."
> That's odd. What signaling purposes are those?
> Do you mean path selection purposes?
> ===
> Section 4
> OLD
>   For example a PE may learn
>   from the remote PEs, the switching capability, the maximum LSP
>   bandwidth of the remote l1vpn interfaces.
> NEW
>    For example a PE may learn
>    the switching capability and the maximum LSP bandwidth of
>    remote L1VPN interfaces from the remote PEs.
> ===
> Section 4
>   "This document proposes
>    the use of the BGP attribute defined in [BGP-TE-ATTRIBUTE] to
>    carry such information."
> Most assuredly it does not!
> Try...
>    "[BGP-TE-ATTRIBUTE] defines a mechanism that could be used
>     for this purpose."
> 
> But I need you to explain why that mechanism is to be 
> preferred over the 
> mechanism proposed in draft-vasseur-ccamp-ce-ce-te.
> ===
> Section 5
> s/(a) PE,/(a) PEs,/
> ===
> Section 5
> You use "should" several times. See the note above about the 
> use of RFC 2119 
> language.
> But also, if you use "should" you need to also describe the 
> corresponding 
> "may" that allows avoidance of the "should".
> ===
> Section 6
> s/of PE to discover/of PEs to discover/
> s/.)./.)/
> ===
> Section 7
> This IANA section will not do!
> The section must:
> - point to the registry and sub-registry by name
> - make an explicit request to IANA
> - suggest a value for allocation
> - state the text for inclusion in the sub-registry
> - give a reference to the relevant section of the I-D
> ===
> Section 8.
> In general, I don't think it is helpful to reference I-Ds 
> that have expired 
> and that will not be restarted.
> === 
> 
> 
> 
> _______________________________________________
> L1vpn mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/l1vpn
> 

_______________________________________________
L1vpn mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l1vpn