Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)
draft-ietf-l2vpn-signaling-08

[Note]: 'Requested Sam lift his discuss based on recent discussions between us, addressed David''s discuss from Pekka by removing reference to bgpvpn-auto document. Remaining discuss is Alex, looking for an implementation report.' added by Mark Townsley

[Note]: 'Part of Sam''s general block on L2VPN. Requested Sam lift his discuss based on recent discussions between us, addressed David''s discuss from Pekka by removing reference to bgpvpn-auto document. Remaining discuss is Alex, looking for an implementation report.' added by Mark Townsley

Note to chairs and authors on how to handle discuss comments

-------- Original Message --------
Subject: draft-ietf-l2vpn-signaling-06.txt
Date: Mon, 20 Feb 2006 19:45:28 +0100
From: Mark Townsley
To: l2vpn-chairs@tools.ietf.org,  erosen@cisco.com,  luo@cisco.com,  bsd@cisco.com,  radoaca@hotmail.com


Please find IESG comments below. At a minimum, you need to address the DISCUSS
comments from Sam, David, and Alex. David's seems to be a small subset of what
Pekka wrote, just the references and adding a discussion on IPv6. Sam's is part
of a bigger issue on L2VPN security requirements in general. Alex is asking for
an implementation report and to be LC'd in PWE3 and IDR.

If I can suggest people to followup on this:

Eric, could you get in contact with Sam on what he is asking for here. That
might digress into a discussion on L2VPN security requirements in general, which
is OK, as I'd like you to give him your background on the MPLS over IP document
in particular.

Chairs, please be sure this is LC'd in PWE3 and IDR

Bruce, perhaps you or Wei could followup on David's comments forwarded from Pekka.

For the implementation report, I need someone to volunteer to put this together.

I'm moving this to "Revised ID needed" for now, as I believe the changes
requested are substantive enough that a new version will have to be issued.

Thanks,

- Mark

[Ballot comment]
From Gen-ART review by John Loughney, supporting David's DISCUSS:

1) Missing references
2) Need some text on IPv6
3) Insufficient discussion on security service signaling.

nits:

Might want to expand VPN in the abstract.
Terminology section wouldn't hurt.

[Ballot discuss]
This draft does not discuss how security services are signaled or
established.  It discusses other similar issues in sufficient detail
that I believe it needs to discuss security service signaling.  Note
that this discuss is dependent on my discuss on the l2vpn requirements
document; as the requirements document currently stands, these
services are not required so they need not be signaled.

[Ballot comment]
By Pekka Savola, from the Ops Directorate:

editorial
---------
                                                                                                     
                                                                                                     
Abstract
                                                                                                     
==> please shorten the abstract.  Could the most salient points be
summarized in 5-10 lines?
                                                                                                     
                                                                                                     
  In Distributed VPLS ([L2VPN-FW], [DTLS], [LPE]), the VPLS
  functionality of a PE router is divided among two systems: ...
                                                                                                     
==> missing references [DTLS] and [LPE] ?
                                                                                                     
  The provisioning, autodiscovery and signaling mechanisms described
  above can all be applied in an inter-AS environment.  As in [2547bis]
                                                                                                     
==> s/2547bis/RFC2547bis/ or change the name of the ref throughout the
document (also elsewhere in the doc)

[Ballot discuss]
I received the following review from the Ops Directorate by Pekka Savola.

I would like you to consider to fix the references as suggested by Pekka and
add a very brief discussion on ipv6.

---

The most troubling issue is this:
                                                                                                     
  An ASBR must maintain labeled IPv4 /32 routes to the PE routers
  within its AS.  It uses EBGP to distribute these routes to other
  ASes, and sets itself as the BGP next hop for these routes.  ASBRs in
  any transit ASes will also have to use EBGP to pass along the labeled
  /32 routes.
                                                                                                     
==> what about IPv6?  Now that I check it,
draft-ietf-l3vpn-rfc2547bis-03.txt doesn't mention "IPv6" either and
neither does the L2VPN charter.  The IETF policy is not to standardize
stuff that doesn't support IPv6 unless there are very strong reasons
to do so.  I hope this is just a misunderstanding, and the issue is
being remedied in other work by L3VPN WG.
                                                                                                     
In any case, the v6 status should likely be at least clarified.
                                                                                                     
substantial
-----------

(All of these are issues with dependencies on what appear to be normative
references which are informative in the spec..)
                                                                                                     
                                                                                                     
  Either LDP (as specified in [LDP] and extended in [PWE3-CONTROL]) or
  L2TP version 3 (as specified in [L2TP-BASE] and extended in [L2TP-
  L2VPN]) can be used as signaling protocols to set up and maintain
  pseudowires (PWs) [PWE3-ARCH].
                                                                                                     
==> should [L2TP-L2PVN] be a normative reference?  From the following
text, it appears this document relies heavily on the L2TPv3 extension,
and L2TP specification -- and parts of this document cannot be
implemented without it.  (The doc seems to be at IETF LC right now.)
  In order to use BGP-based auto-discovery as specified in [BGP-AUTO],
  there must be at least one globally unique identifier associated with
  a VPLS, and each such identifier must be encodable as an 8-byte Route
  Distinguisher (RD).  If the globally unique identifier for a VPLS is
  an RFC2685 VPN-id, it can be encoded as an RD as specified in [BGP-
  AUTO].  However, any other method of assigning one or more unique
  identifiers to a VPLS and encoding each of them as an RD (using the
  encoding techniques of [RFC2547bis]) will do.
                                                                                                     
==> it seems to me that [BGP-AUTO] might need to be a normative reference.
It seems that BGP auto-discovery parts of this depend heavily on [BGP-AUTO]
and cannot be implemented without it.  The same seems to apply to
[RFC2547bis].  Unfortunately BGP-AUTO hasn't reached the IESG yet.
                                                                                                     
==> Btw. s/RFC2685 VPN-id/RFC2685 VPN-id [RFC2685]/
                                                                                                     
  [PW-SWITCH] describes an approach to "switching" packets from one
  pseudowire to another at a particular node.

==> (and elsewhere.)  [PW-SWITCH] is an expired invididual submission.  It
seems as if it's a normative reference -- something that needs to be
implemented in order to implement parts of this spec.  Unless I'm mistaken
about this, this could be a Major Problem.
                                                                                                     
  This document assumes the assignment of an AFI and a SAFI for L2VPN
  NLRI.  Both AFI and SAFI may be the same as the values assigned for
  [BGP-VPLS].
                                                                                                     
==> this spec doesn't seem to be implementatable until the IANA codepoints
have been granted so [BGP-VPLS] should be a normative reference, I think?
(It's in IESG evaluation in this call.)

IANA Comments:
As described in the IANA Considerations section, we understand this document to have NO IANA Actions.  However, when this document is approved for publication as an RFC, there are 2 references that need to be updated in the following registry: http://www.iana.org/assignments/pwe3-parameters
This assignments were made via ietf-pwe3-iana-allocation-15.txt.

PROTO

1) Have the chairs personally reviewed this version of the Internet
  Draft (ID), and in particular, do they believe this ID is ready
  to forward to the IESG for publication?

Yes.


2) Has the document had adequate review from both key WG members
  and key non-WG members?

Yes.

  Do you have any concerns about the
  depth or breadth of the reviews that have been performed?

No.


3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.


4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of?  For
  example, perhaps you are uncomfortable with certain parts of the
  document, or have concerns whether there really is a need for
  it.  In any event, if your issues have been discussed in the WG
  and the WG has indicated it that it still wishes to advance the
  document, detail those concerns in the write-up.

All concerns have been addressed and agreed upon.


5) How solid is the WG consensus behind this document? Does it
  represent the strong concurrence of a few individuals, with
  others being silent, or does the WG as a whole understand and
  agree with it?

Strong agreement, from a broad variety of individuals.


6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarise the areas of conflict in
  separate email to the Responsible Area Director.

No.


7) Have the chairs verified that the document adheres to all of the
  ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.


8) Is the document split into normative and informative references?

Yes.

  Are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (note here that the RFC editor will not publish an RFC with
  normative references to IDs, it will delay publication until all
  such IDs are also ready for publication as RFCs.)

No.


9) For Standards Track and BCP documents, the IESG approval
    announcement includes a writeup section with the following
    sections:

    - Technical Summary
There are a number of different kinds of "Provider Provisioned Layer
2 VPNs" (L2VPNs).  The different kinds of L2VPN may have different
"provisioning models", i.e., different models for what information
needs to be configured in what entities.  Once configured, the
provisioning information is distributed by a "discovery process".
When the discovery process is complete, a signaling protocol is
automatically invoked.  The signaling protocol sets up the mesh of
Pseudowires (PWs) that form the (virtual) backbone of the L2VPN.  Any
PW signaling protocol needs to have a method which allows each PW
endpoint to identify the other; thus a PW signaling protocol will
have the notion of an endpoint identifier.  The semantics of the
endpoint identifiers which the signaling protocol uses for a
particular type of L2VPN are determined by the provisioning model.
This document specifies a number of L2VPN provisioning models, and
further specifies the semantic structure of the endpoint identifiers
required by each provisioning model.  It discusses the way in which
the endpoint identifiers are distributed by the discovery process,
especially when the discovery process is based upon the Border
Gateway Protocol (BGP).  It then specifies how the endpoint
identifiers are carried in the two signaling protocols that are used
to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2
Tunneling Protocol (L2TPv3).


    - Working Group Summary
After WG Last Call, Luca Martini had raised an issue with
respect to whether or not there needed to be coordination of AII
Types between the l2vpn-signaling draft and the emergent MS-PW work.
Luca proposed a solution to this dilemma on the L2VPN WG list:
http://www.ietf.org/mail-archive/web/l2vpn/current/msg01121.html

A discussion ensued between Bruce, Luca, Chris Metz, Florin,
Mustapha, Vach & Shane to resolve it.  In summary, we have all agreed
that l2vpn-signaling is its own application and its use of Type-1
AII's is sufficient for it.  In fact, procedures developed in
l2vpn-signaling already account for PW routing/stitching & signaling
as it relates to D-VPLS, (with Type-1 AII's), but do not give one the
granularity of routing that MS-PW is aiming for.  Another key difference
is that l2vpn-signaling is focused on auto-discovery mechanisms for
groups of PW's (e.g.: L2VPN's), whereas MS-PW is focused on both
routing and signaling invidual PW's (not groups of PW's).  In fact,
it's not clear that MS-PW will initially be designed to support
routing+signaling of groups of PW's, (which is another thing that
distinguishes it from l2vpn-signaling).


    - Protocol Quality
The protocol is in the planning stages of implementation and will
eventually be implemented by at least two vendors.

-------- Original Message --------
Subject: draft-ietf-l2vpn-signaling-06.txt
Date: Wed, 07 Dec 2005 12:29:22 -0700
From: Shane Amante
To: Mark Townsley
CC: Vach Kompella


Mark,

The issue Luca raised with respect to using the same or different AII
Types for l2vpn-signaling and MS-PW is now resolved.  Could you please
progress l2vpn-signaling, with the ultimate goal of publishing it as a PS?

For the record, we had a conversation between Bruce, Luca, Chris Metz,
Florin, Mustapha, Vach & I to resolve it.  In summary, we have agreed
that l2vpn-signaling is its own application and its use Type-1 AII's is
sufficient for it.  In fact, procedures developed in l2vpn-signaling
already account for PW routing/stitching & signaling as it relates to
D-VPLS, (with Type-1 AII's), but do not give one the granularity of
routing that MS-PW is aiming for.  Another key difference is that
l2vpn-signaling is focused on auto-discovery mechanisms for groups of
PW's (e.g.: L2VPN's), whereas MS-PW is focused on both routing and
signaling invidual PW's (not groups of PW's).  In fact, it's not clear
that MS-PW will initially be designed to support routing+signaling of
groups of PW's, (which is another thing that distinguishes it from
l2vpn-signaling).

It sounds like Florin misunderstood the issue and was actually
advocating use of AII Type 2 for MS-PW and wasn't very concerned with
Type-1's in l2vpn-signaling.  It also sounds like Mustapha had the same
misunderstanding and raised an issue relative to auto-discovery of
MS-PW's using Type-2 AII's, but which is orthogonal to l2vpn-signaling,
and may or may not even be an issue.  No one else had any concerns and,
in fact, both Florin and Mustapha did not intend to block
l2vpn-signaling from moving forward.

I'll also send a message to the list (for the archives) asking you to
progress it to PS.

Thanks,

-shane

-------- Original Message --------
Subject: draft-ietf-l2vpn-signaling-06.txt
Date: Mon, 5 Dec 2005 23:57:32 -0700
From: Shane Amante
To: townsley@cisco.com
CC: Vach Kompella


Mark,

Just a heads-up that Luca has sent a message to the L2VPN WG mailing 
list explaining why he no longer has an objection to draft-ietf-l2vpn-
signaling-06.txt from being forwarded to the IESG.  See the list/
archive, but Mustapha and Florin both appear to have concerns with 
Luca's explanation.  After Mustapha's e-mail, Bruce Davie expressed 
concerns over Mustapha's objection and sent Vach & I an e-mail asking 
if we would send you the OK to forward the l2vpn-signaling doc on to 
the IESG.

I informed Bruce that I wasn't comfortable sending it to the IESG, at 
the moment, and followed it up with the following explanation:
---snip---
I agree the I-D has passed WG LC.  However, I don't see the point in 
rushing a doc to the IESG if there are, what appears to be, 
significant concerns by list members with doing so.  That said, I 
don't prefer opening up the I-D to another LC, unless it's absolutely 
necessary.  No one has suggested it on the list, nor am I sure that 
is even necessary at this point.

Ultimately, I would like a little time to do some due diligence. 
Specifically:
1) For my own edification, I'd like to grab some time with Luca to 
understand the issue better, because it's not clear to me there is an 
issue.  On the one hand, I can see Luca's point that MS-PW is (at 
this point) strictly for setting up individual PW's, hence the AGI is 
not necessary.  However, in terms of future extensibility of MS-PW, I 
can see Florin's point of [potentially] wanting to connect both SS-
PW's and MS-PW's into an L2VPN, in which case AII Type 2 would be a 
necessity (for global uniqueness).
2) Send a message on to Mark that Luca has sent the message to the 
list, which removes the previous blocker, but Florin/Mustapha have 
raised some issues that we are considering/working through.
3) After the above, see if Florin/Mustapha will come around to the 
arguments proposed by Luca & Chris Metz.  In other words, I prefer 
that we work through the issue(s) and not have to burden Mark & the 
IESG with sorting it out on our behalf, (which unfortunately would 
probably make the issue take longer to resolve).

Does this sound reasonable?
---snip---

Let me know if you have objections/concerns.  Otherwise, I'll 
continue down the due diligence path and let you know what becomes of 
that.

-shane