Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
draft-ietf-l2vpn-vpls-ldp-09

IANA follow-up comments:
We received the following response regarding the IANA questions:

The section moved to Section 6.2.1. This goes into the LDP TLV registry
(http://www.iana.org/assignments/ldp-namespaces).

Thanks.

-Vach

[Ballot discuss]
I would like to see a title change in both vpls-bgp and vpls-ldp to make it clear that they're different.  In particular, I don't think "over MPLS" accurately captures the difference between the two protocols.

[Ballot comment]
First of all, I agree with Ted's DISCUSS.

I received the following comments from the Ops Directorate by Pekka Savola that you might want to consider to improve the document:

substantial
-----------
                                                                                                     
7.2. VPLS Learning actions
                                                                                                     
  Learning is done based on the customer Ethernet frame as defined
  above.  The Forwarding Information Base (FIB) keeps track of the
  mapping of customer Ethernet frame addressing and the appropriate
  PW to use.  We define two modes of learning: qualified and
  unqualified learning. [...]
                                                                                                     
==> unqualified learning (if I understood it correctly) really breaks
the network badly, are you sure you want to even specify that?
Ethernet switches which don't have VLAN-specific spanning trees (a
model which you're pushing here) have caused TONS of operational grief
.. especially when you have multi-port Ethernet cards which use the
same MAC address for all ports (*cough* Sun *cough*)..
                                                                                                     
I don't think you should support unqualified learning *at all* because
it's so badly broken, and you also break the customer's VPLS layer 2
by mixing different VLANs' MAC addresses together by doing so.  This
is not Layer 2 transparent so I'm not sure if it could be called
proper L2VPN service.  If an ISP doesn't want to deal with multiple
VLANs, the ISP should just refuse carry anything that except untagged
Ethernet!
                                                                                                     
But if you have to specify it, it needs a *lot* more health warnings!
                                                                                                     
9.1. MAC Address Aging
                                                                                                     
  PEs that learn remote MAC addresses SHOULD have an aging mechanism
  to remove unused entries associated with a PW label.  This is
  important both for conservation of memory as well as for
  administrative purposes.  For example, if a customer site A is shut
  down, eventually, the other PEs should unlearn A's MAC address.
                                                                                                     
==> this SHOULD should probably be a MUST?  If MAC addresses are not aged
out, they could stay around for ever, and that results in very well known
operational problems e.g., when hosts move from one port to another.
                                                                                                     
semi-editorial clarifications
-----------------------------
                                                                                                     
    - If the frame, as it arrives at the PE, has an encapsulation
        that is used by the local PE as a service delimiter, i.e., to
        identify the customer and/or the particular service of that
        customer, then that encapsulation may be stripped before the
        frame is sent into the VPLS.  As the frame exits the VPLS,
        the frame may have a service-delimiting encapsulation
        inserted.
....
  By following the above rules, the Ethernet frame that traverses a
  VPLS is always a customer Ethernet frame.  Note that the two
  actions, at ingress and egress, of dealing with service delimiters
  are local actions that neither PE has to signal to the other.
==> How does the PE know whether the VLAN tag is a service delimiter or not?
(looking at PWE3-ETHERNET, this is probably manual config, it wouldn't hurt
to talk about that a bit somewhere here as well) How does egress PE know
whether to reinsert a service delimiting VLAN ID, and how to choose it?
Isn't this something that needs to be communicated between PEs?
                                                                                                     
  As an application of these rules, a customer frame may arrive at a
  customer-facing port with a VLAN tag that identifies the customer's
  VPLS instance.  That tag would be stripped before it is
  encapsulated in the VPLS.  At egress, the frame may be tagged
  again, if a service-delimiting tag is used, or it may be untagged
  if none is used.
                                                                                                     
==> There are some assumptions here that I don't understand.  Are describing
a scenario where customer has multiple VPLS instances (e.g., has 10 sites,
VPLS 1 for VLAN 1 reaches all of them, VPLS 2 for VLAN 2 reaches the first
five, VPLS 3 for VLAN 3 rearches the last 5, or something) and needs a
mechanism to signal the "distribution" of the VPLS?  If yes, that could
possibly be clarified a bit somewhere.
                                                                                                     
How does the PE know which VPLS instances the customer has the right to
"subscribe to"?  Manual config?  How is this information syncronized across
all PEs?
                                                                                                     
Just trying to ensure that the customer cannot join someone else's VPLS by
picking the right VLAN ID...
                                                                                                     
                                                                                                     
editorial
------------
                                                                                                     
  The use of IGMP snooping and PIM snooping techniques should be used
  to improve multicast efficiency.  A description of these techniques
  is beyond the scope of this document.
                                                                                                     
==> This is a dangerous statement, as VPLS services should be
IP-agnostic, and (for example) IGMP snooping may not be able to deal
well with IPv6, MLD, newer versions of IGMP, etc.  So, I'd consider
removing this text or adding a bit of warning, like below -- but I
really think you shouldn't be recommending something like this.
                                                                                                     
  The use of IGMP snooping and PIM snooping techniques may be used
  to improve multicast efficiency, but care should be taken to ensure
  transparency of unknown traffic (e.g., IPv6 multicast, newer IGMP/MLD
  versions, etc.) .  A description of these techniques is beyond the
  scope of this document.

[Ballot discuss]
Would it be valuable to add an IESG note pointing out that there are two solutions and pointing in each to the other?  The "let the market decide" result from L2vpn is clearly within their purview, but should the IESG highlight that in the document itself, as it is in Mark's write-up?

[Ballot comment]
Gen-ART review comments from Elwyn Davies:

The document needs a normative reference to RFC2119 to be pointed at by the conventions section. [Scott Hollenbeck holds a DISCUSS for this.]

Editorial nits (input to copy editing):
The Boiler Plate is non-standard.
Location of the conventions section and section numbering of ToC needs fixing.
s4.1: Acronyms GRE, L2TP and IPSEC unexpanded.
s6.1.1: Acronyms AGI, TAII, SAII are unexpanded.
s9, para 2: s/a identifier/an identifier/

s15: should refer to RFC3036 (LDP) registry in which MAC List TLV type is to be registered.

[Ballot comment]
Gen-ART review comments from Elwyn Davies:

The document needs a normative reference to RFC2119 to be pointed at by the conventions section. [Russ Housley  holds a DISCUSS for this.]

Editorial nits (input to copy editing):
The Boiler Plate is non-standard.
Location of the conventions section and section numbering of ToC needs fixing.
s4.1: Acronyms GRE, L2TP and IPSEC unexpanded.
s6.1.1: Acronyms AGI, TAII, SAII are unexpanded.
s9, para 2: s/a identifier/an identifier/

s15: should refer to RFC3036 (LDP) registry in which MAC List TLV type is to be registered.

[Note]: 'This document and draft-ietf-l2vpn-vpls-bgp are different solutions to similar problems. L2VPN agreed to advance both and essentially "let the market decide."' added by Mark Townsley

IANA Comments:
The IANA Considerations section says the following:
 
  The type field in the MAC TLV is defined as 0x404 in section 4.2.1
  and is subject to IANA approval.

We do not see a section 4.2.1.  We are not sure which registry this registration needs to placed in.  Need clarification.

[Ballot discuss]
Please add a normative reference to RFC 2119 and cite it in section 1.

Section 6.2.1: "byte" is a hardware-dependent term.  Please use "octet" if an 8-bit value is being described.

Proto Questionairre

1) Have the chairs personally reviewed this version of the ID and do
    they believe this ID is sufficiently baked 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? Do you have any concerns about the depth or
    breadth of the reviews that have been performed?

Yes.  Technical reviews done by Ina Minei, Eric Gray, Bob Thomas and
Dimitri Papadimitriou.

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

Security considerations are well understood.

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 whether there really is a need for it, etc., but at the same
    time these issues have been discussed in the WG and the WG has
    indicated it wishes to advance the document anyway.

No.

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.

6) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarize what are they upset about.

No.

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

Yes.

8) Does the document a) split references into normative/informative,
    and b) are there normative references to IDs, where the
IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (Note: 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.)

Yes.

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

    - Technical Summary
The service described in this document, the Virtual Private
LAN Service (VPLS), also known as Transparent LAN Service,
offers a variant of a Layer 2 Virtual Private Network (L2VPN).
In the case of VPLS, a multipoint network connects the VPN
customers, in contrast to the more traditional Layer 2 VPNs,
which are point-to-point in nature. This document describes the
functions required to offer VPLS, mechanisms for signaling a
VPLS, and rules for forwarding and learning from VPLS frames
across a packet switched network, how to separate traffic in different
VPN and to de-multiplex traffic at the PE routers. The VPLS-LDP is
agnostic when it comes to discovery of VPLS end-points.

    - Working Group Summary
The VPLS solutions have been one of the controversies of the
VPN working groups.  There have been two sets of solutions and
much arguing on the relative merits of these solutions. An agreement
was reached that it is not really the choice of signaling protocol
that is the major difference between the LDP and BGP based
solutions, but the kind of environment they are targeted for.
VPLS-LDP targets networks (e.g., metro) where BGP is typically
not run or LDP is used for other L2VPNs (e.g., VPWS).  On the other
hand, VPLS-BGP targets those networks where L3VPNs using BGP
are also deployed.  The VPLS-BGP has been through a number of
reviews, including reviews in the l2vpn working group and the idr
group.  The same type of review has been done for vpls-ldp from the
l2vpn and mpls working groups.

    - Protocol Quality
The protocol is implemented and deployed. A fair number of
vendors have implemented the spec. The number of deployments is
large. We have not had any reviewer standing up and saying that
there is any need for major rework.



>
>
>

From LDP Review

-------- Original Message --------
Subject: vpls-ldp draft
Date: Wed, 13 Jul 2005 15:10:34 -0700
From: Vach Kompella
To: 'Mark Townsley' , 'Amante, Shane'


Mark, Shane,

There were a lot of comments from the four reviewers (Bob Thomas, Ina
Minei, Eric Gray, and Dimitri Papadimitriou).  Most of them were
typographical.  There were some comments on scalability of LDP and
convergence times.  I don't buy that and we had a little discussion on
that.  If anything I would let that develop in an applicability
statement.

However, I've tried my implementation with over 200 peers and several
thousand VPLS instances on a single PE and there were no issues (other
than the test equipment I used to simulate the 200 peers could not keep
up with emulating more than about 50 routers each, so I had to have
multiple test nodes).  I believe Luca has brought this up several times
in PWE3 that scalability of LDP in this targeted mode, and BGP are two
completely different things.

Convergence is not an issue - it isn't as if the FECs distributed have
to converge.  They are sent and not propagated, there is no SPF
computed, etc.

Another issue that was brought up was the format and procedures for the
Address Withdraw Message with a MAC Address List TLV.  Duplicate text
was removed.  Cleanup around the use of the term "notification message"
(we were using lower case to signify a generic notification so as not to
confuse it with an LDP Notification Message).

Dimitri gave me a page of second round comments that I have addressed
also.

I have sent Shane a modified version of the questionnaire, and attached
Loa's comments so he can form his own responses.

IMHO, it is ready for publication.

Vach Kompella
IP Division, Alcatel
vach.kompella@alcatel.com
+1 650 623-2556

[Note]: 'Moved to wrong state (External Party). Intended to move to Expert Review (as it is awaiting expert review of the LDP modifications by the MPLS WG).' added by Mark Townsley

[Note]: '
Awaiting review by MPLS WG.

-------- Original Message --------
Subject: [mpls] MPLS working group review of draft-ietf-l2vpn-vpls-ldp-06.txt
Date: Mon, 21 Mar 2005 16:46:17 +0100
From: Loa Andersson
To: mpls@ietf.org

All,

the MPLS working group will review the
draft-ietf-l2vpn-vpls-ldp-06.txt

The review will focus on the use LDP in this draft, but
other comments based on MPLS wg specifications are welcome.

Not that this is not a discussion on how feasible it is
to use LDP as a signaling protocol for L2VPNs, but on the
fashion it is used in.

The working group review end April 10th. Please send comments
to the mpls wg mailing list, the wg co-chairs.

/Loa
--
Loa Andersson' added by Mark Townsley