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

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 26 Sep 2011 15:39:12 +0200

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.

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.

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

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

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.

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

- 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,…".

- 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

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

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

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

Best regards

Matthew

---

From: Bhupesh Kothari <[email-masked]>
Date: Mon, 26 Sep 2011 14:03:34 -0700

Bocci, Matthew (Matthew) <[email-masked]> wrote:

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

Is this a blocker for this draft to get published?  If not, I would
like to not include your suggestion.

Or, to be fair, can I add the following:

"
The IETF techonology for this function is specified in RFC6074 and
RFC4447 but following are the disadvantages of each:

<disadvantages>
"

I don't want a reader to assume that the IETF "approved" technology
equals "better" technology.  There are pros and cons of each, and SPs
are the ultimate judge of which solution meets the requirements of
their networks.  In this case, this is 8/10 year old technology with
many SP adoptions, even after IETF decided to not purse it.

In addition, this is an Informational RFC and so it is clear to
everyone that IETF did not adopt it for standards track.  What more is
required?

> in
> addition to the suggestions on the list that implementations of this draft must
> also comply to these RFCs.  

What is the rationale for this?

Stating this adds no value, increases unnecessary complexity for both
vendors and customers and is irrelevant, at least from a technical
point of view.

Neither RFC that you are mentioning is required for proper functioning
of this draft.  Why would you like to force a vendor to implement
complete disjoint techonologies?  As a result, you are also forcing
the provider to incur the cost of extra code which is not at all
needed if he/she wishes to deploy this techology.

Also note that in all existing deployment cases, the routers that have
implemented this draft also supports RFC4447.

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

This has been discussed.  Conclusion is to replace 'standards action'
with '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.

I am OK with 'out of scope ...' statement. 

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

Agree.

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

There is only one TLV defined in the draft (Table 2).  Can you point
which other places need changes?

> 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,…".

Agree.

> RFC3985 is probably the correct reference.

Agree.

> 
> - 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 intention of this sub-section is to highlight the better scaling
properties of BGP VPWS in comparision to BGP L3 VPNs.  In order to
highlight, the sub-section has a couple of paragraphs on what the
L3 VPN scaling issues are on PEs and RRs that also hold the BGP VPWS
state. 

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

The content is useful.  It is also a bit historic in the sense that
when this draft came out (8/10 years back), it was more appropriate to
contrast L2 and L3 VPNs.

I am OK if this section was removed. 

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

Agree. 

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

Agree.

> Matthew

Thanks for the review.

Bhupesh

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Tue, 27 Sep 2011 12:26:35 +0200

Bhupesh,

Thanks for the quick response.
Please see below.

Matthew

>like to not include your suggestion.

Yes, this needs to be included. The rationale for the statement is to
distinguish an AD-sponsored Informational RFC from an Informational RFC
that is the product of a working group.

>many SP adoptions, even after IETF decided to not purse it.

I do not agree that this draft should debate the pros and cons of the
output of PWE3 and L2VPN. I am sure there are many other channels to do
that. I think the value in this draft is in documenting this alternative
approach that has been implemented and deployed, and to do it to a
sufficient level of detail that is useful to other implementers, not to
position this within the market.

>everyone that IETF did not adopt it for standards track.  What more is

Please see my comment above about AD-sponsored vs. the product of a WG.

>implemented this draft also supports RFC4447.

The two RFC's cited are the IETF standards track RFCs for endpoint
discovery and signalling PWs used for VPWS. It doesn't sound like it is
burdensome to implement RFC4447 as well if all existing deployments have
it. I was reiterating the sentiments of others who have provided IETF last
call comments on the draft. The way I would view this is that if you
signal PWs, you must at least support tLDP, and in addition BGP can be
supported. It is very important that we do not to create a situation where
a service provider can inadvertently create non-interoperable islands in
their infrastructure.

>This has been discussed.  Conclusion is to replace 'standards action'

Thanks

>I am OK with 'out of scope ...' statement.

Thanks

>which other places need changes?

I think it would also help if figure 3 showed the packet structure. You
could use the following figure from RFC4619 as an template:

  +-------------------------------+
  |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
  +-------------------------------+
  |      PW label                 |  4 octets
  +-------------------------------+
  |       Control Word            |
  |      (See Figure 4)           | 4 octets
  +-------------------------------+
  |            Payload            |
  |      (Frame relay frame       |
  |       information field)      | n octets
  |                               |
  +-------------------------------+

>> the IETF has standardised two VPLS methods. I propose modifying this to
>>"Šwhich
>> describes a method for VPLS,Š".
>
>
>Agree.
>
>
>> 

OK. Maybe you could add a sentence explaining that that these scaling
issues may also affect the state space available for BGP VPWS on PEs and
RRs that host both VPN types.

>I am OK if this section was removed.

Thanks. I don't disagree that it is useful, it is just out of context so
it would be better if it could be removed.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Sep 2011 12:49:13 +0100

On 26/09/2011 22:03, Bhupesh Kothari wrote:
> Bocci, Matthew (Matthew)<[email-masked]>  wrote:
>
>> Comments:
>>
>> Major Issues:
>>

Bhupesh

There exists an IETF Standards Track solution to the problem.

The IETF strongly prefers a single solution, and strongly prefers
a Standards Track solution over a WG informational over
an individual submission. This is an individual submission.

Therefore you have three choices in the matter. You can either
include a statement in the document noting that there
exists another IETF standards track protocol that achieves
the same functionality and which MUST be implemented
in a product with the functionality described in this draft
(Please see Andy Malis' email during IETF LC for some words).
Alternatively you can demonstrate a clear and distinct applicability
for this protocol and attempt to get the L2VPN WG to
adopt the draft. Given the existing standards track documents
from the L2VPN WG, that approach seems most unlikely to
succeed. Finally if neither of those approaches are acceptable,
you can withdraw the draft from  publication.

- Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html