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

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

Hi Adrian, 

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

Certainly. BGP has all the necessary mechanisms to achieve both
VPN membership distribution without a need to carry
specific IDs that uniquely identify the VPNs. 

Since the type of l1vpn service we are interested in is a 
port-based VPN service, from a control plane point of view 
all what is needed is the ability for the remote PEs to
discover the set of PEs that have VPNs in common and the set
of ports associated with the VPNs. BGP allows that through the use of
BGP-MP and with the use of extended community (such as route target) 
for the membership and topology distribution. This scheme
plays both the role of a VPN-ID and topology information 
distribution without a need for an explicit advertisement 
of VPN-IDs.

Do you (or why do you) think a VPN-ID is necessary in the discovery 
process?.

Hamid.

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

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