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

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

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