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
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
