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

[Kireeti Kompella <[e-mail]>]

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

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

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

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

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

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

Regards,
Kireeti.

> Best regards
> 
> Matthew