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

["Adrian Farrel" <[e-mail]>]

Oh, could you also explain why it is not necessary to advertise the VPN ID. 
Or did I miss it?

A
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Friday, September 28, 2007 3:13 PM
Subject: [L1vpn] Chair review of draft-ietf-l1vpn-bgp-auto-discovery-02.txt


> Hi,
>
> 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