Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt

["Bocci, Matthew (Matthew)" <[e-mail]>]

Hi Kireeti,

Thanks for your responses. Please see below.

Regards
Matthew

On 03/01/2012 20:50, "Kireeti Kompella" <[e-mail]> wrote:

>Hi Matthew,
>
>On Sep 26, 2011, at 6:39 , Bocci, Matthew (Matthew) wrote:
>
>> Hello,
>> 
>> I have been selected as the Routing Directorate reviewer for this
>>draft. The Routing Directorate seeks to review all routing or
>>routing-related drafts as they pass through IETF last call and IESG
>>review. The purpose of the review is to provide assistance to the
>>Routing ADs. For more information about the Routing Directorate, please
>>see http://www.ietf.org/iesg/directorate/routing.html
>> 
>> Although these comments are primarily for the use of the Routing ADs,
>>it would be helpful if you could consider them along with any other IETF
>>Last Call comments that you receive, and strive to resolve them through
>>discussion or by updating the draft.
>
>Thanks for your review!  See below for specific responses.
>
>> Document: draft-kompella-l2vpn-l2vpn-07.txt
>> Reviewer: Matthew Bocci
>> Review Date: 26-09-11
>> IETF LC End Date: 26-09-11
>> Intended Status: Informational
>> 
>> Summary:
>> 
>> I have some major concerns about this document, and some minor concerns
>>that I think should be resolved before the document is published.
>> 
>> 
>> Comments:
>> 
>> Major Issues:
>> 
>> - Relationship to published and on-going work in the L2VPN and PWE3
>>working groups. This draft describes an alternative to the procedures
>>for signalling PW labels used in pt-pt layer 2 VPNs (VPWS) and for
>>auto-discovery of endpoints participating in a L2VPN. The existing
>>IETF-approved technologies use LDP for the signalling (as described in
>>RFC4447) and a combination of that with BGP for auto-discovery
>>(RFC6074). Since this draft describes an alternative that was rejected
>>by the L2VPN WG, I would suggest adding a disclaimer to the abstract and
>>introduction, as per the recommendation of RFC5742, along the lines of
>>"The IETF technology for this function is specified in RFC6074 and
>>RFC4447", in addition to the suggestions on the list that
>>implementations of this draft must also comply to these RFCs.
>
>I had a discussion with Andy Malis about this, and we came to this
>conclusion:
>
>"The draft currently has the following (2nd last para in the
>Introduction):
>
>  It may be instructive to compare the approach in [RFC4447] with the
>  one described here, keeping in mind that the solution described
>  therein does not include auto-discovery.
>
>If it's acceptable to you, I can change that to:
>
>  It may be instructive to compare the approach in [RFC4447] with the
>  one described here, keeping in mind that the solution described
>  therein does not include auto-discovery.  Devices implementing the
>  solution described in this document MUST also implement the approach
>  in [RFC4447].
>
>and move RFC 4447 to a normative reference."
>
>(which he agreed with)
>
>I could further change that to:
>
>  It may be instructive to compare the approach in [RFC4447] and [RFC6074]
>  (these are the IETF approved technologies for the functions described in
>  this document, albeit using two separate protocols) with the one
>  described here.  Devices implementing the solution described in this
>  document MUST also implement the approach in [RFC4447] and [RFC6074].

This paragraph is fine with me. Thanks!

>
>> - Section 9: IANA Considerations. This section requests a registry be
>>created with standards action code points. I believe this is not
>>appropriate as this is an informational draft. There has already been
>>some discussion on this point on the list, and that is noted as a part
>>of this review.
>
>I'll be happy to change that to Expert Review.

Fine with me.

>
>> - Section 5: Layer 2 VPN interworking. This section introduces a layer
>>2 transport service for IP packet. However, just encapsulating IP
>>packets between PEs will not be sufficient for a layer 2 VPN service
>>between the CEs. You also need to support something to allow L2 address
>>resolution between the CEs, for example translation of the neighbour
>>discover protocols (e.g. ARP over Ethernet and InvARP over FR). Since
>>this is describing the L2VPN, and not just the PW encapsulation, I think
>>this section should either say how this is done with BGP
>>(draft-ietf-l2vpn-arp-mediation uses LDP) or just say it is out of scope
>>of this particular draft and the L2 address is statically configured.
>
>Okay.
>
>> Minor Issues:
>> 
>> General:
>> - The draft mainly discussed pt-pt L2VPNs. The general term for this is
>>VPWS, but this term is not mentioned anywhere. It would help to clarify
>>with a statement in the introduction that this the subject of the draft.
>
>Okay.
>
>> - It would help if the figures showing the TLV structures showed the
>>detailed structure, throughout, including bit fields, etc, in line with
>>common practice in IETF RFCs.
>
>I'll change Figure 2; I'm not sure this is particularly helpful.  When
>you say "throughout", what are other places are your referring to?

If you can just change Figure 2, then this is fine with me.

>
>> - 1. Introduction, 5th paragraph:
>> "Technically, the approach proposed here uses the concepts and
>>    solution and described in [RFC4761], which describes VPLS, a
>>    particular form of a Layer 2 VPN."
>> 
>> This reads as if RFC4761 is *the* description of VPLS. This is not the
>>case and the IETF has standardised two VPLS methods. I propose modifying
>>this to "Šwhich describes a method for VPLS,Š".
>
>Okay.
>
>> - 1.1 Terminology. Final paragraph.
>>    "These will be referred to as Attachment
>>    Circuits (ACs), following [RFC4447].  Similarly, the entity that
>>    connects two attachment circuits across the Service Provider network
>>    is called a pseudo-wire (PW)."
>> 
>> RFC3985 is probably the correct reference.
>> Also: 
>>  s/pseudo-wire/pseudowire
>
>Okay.
>
>> - 1.2.5: PE Scaling
>> This section spends a lot of time discussing the scaling issues of L3
>>VPNs. I am not sure why this is required in a BGP L2VPN draft, unless
>>the issue is that because the control plane is the same, many of the
>>same scaling considerations apply. Please can you clarify if this is
>>true, and if so make such a note in the text?
>
>The point of sections 1.2 and 1.3 is to give SPs and their customers
>things to consider when choosing between a L2 or a L3 VPN.  SPs in
>particular may want to understand considerations for the PE's RIB and FIB
>in offering these two types of VPNs; the choice of BGP does influence
>that.
>
>More generally, these two sections were of help to VPN customers to
>understand the implications of L2 vs. L3 VPNs, as evidenced by their
>comments to me; as such, I would prefer to leave them in.

OK 

>
>> - 1.3: Advantages of Layer 3 VPNs
>> I do not think this adds any value to a draft on L2 VPNs. The content
>>may be useful elsewhere, but I think it would be better if this was
>>removed from this draft.
>> 
>> - 3: Operation of Layer 2 VPNs
>> "In what follows, Frame Relay serves as the Layer 2 medium, and each
>>    CE has multiple DLCIs to its PE, each to connect to another CE in the
>>    VPN.  If the Layer 2 medium were ATM, then each CE would have
>>    multiple VPI/VCIs to connect to other CEs. "
>> 
>> I think I know what you mean by "medium" I.e. The underlying link
>>layer, where each group of DLCIs is an AC in the RFC3985 sense, plus
>>DLCI acts as a demarkation of a L2VPN service between the PE and CE. If
>>so, I think it would help to add this clarification.
>
>Would it help if I changed "medium" to "media", which seems to be more
>common, if somewhat non-grammatical?

OK.  

>
>> - 6.3: IP-Only Layer 2 Interworking:
>> 
>>          +----------------------------+
>>          | Tunnel |  VPN  |    IP     |     VPN label is the
>>          | Encap  | Label |  Packet   |     demultiplexing field
>>          +----------------------------+
>> 
>>           Figure 3: Format of IP-only Layer 2 interworking packet
>> 
>> I think the field marked "Tunnel Encap" should instead be labelled "PSN
>>Transport Header" or "MPLS Transport Header", in common with the other
>>encapsulation RFCs that you have referenced.
>
>Okay, PSN T H it is.

Thanks

>
>Regards,
>Kireeti.
>
>> Best regards
>> 
>> Matthew