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, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
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.
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 18-Sep-15
IETF LC End Date: Not Known
Intended Status: Proposed Standard
I am not an IPv6 expert and this can be the reason for some of my concerns about the draft.
My experience with L2TPv3 is also outdated. So I’d like to ask the Routing ADs to take my comments with a big grain of salt.
I have one significant concern about this document and recommend that the Routing ADs discuss these issues further with the authors. I also have several minor concerns about the document that I think should be resolved
before publication, and I have find a couple of nits.
As I see it, the draft is built around three key ideas:
IPv6 addresses, due to their unlimited availability, can be used to identify attachment circuits (or VSI forwarders) of L2TPv3 sessions (and not just tunnel endpoints
as in RFC 3931).
With IPv6 addresses used for identifying L2 circuits or VSI) to be connected by L2TPv3 PWs, L2TPv3 Session ID processing in the data plane can be bypassed. I can
guess that this really simplifies data plane handling and that this was the prime driver for the technology the draft defines, but this is just a guess.
L2TPv3 sessions identified by IPv6 addresses can be used to provide operator-managed services that neither need nor use L2TPv3 control plane. The control plane
functionality is moved to an external management entity that can access both endpoints of the service, sets the service up and continuously intervenes in its operation until it tears down the service.
The term “keyed IPv6 tunnel” refers to an L2TPv3 session that bypasses Session ID processing and relies on IPv6 addresses of its endpoints. Depending on the nature of emulated Ethernet service, these IPv6 addresses
are used to identify either L2 attachment circuits for P2P services or Virtual Switching Instances (VSI) for MP2MP services.
Since L2TPv3 control plane is by design left out of scope of the draft, it mainly deals with the data plane. Additional information about the management plane aspects can be found in the
YANG Data Model draft.
The draft is not easy to read and understand (at least to me), mainly because pieces of important information are often distributed throughout the text.
One example illustrating this complaint:
The first sentence in Section 2 states that “Static local configuration creates a one-to-one
mapping between the access-side L2 attachment circuit and the IP address used in the network-side IPv6 encapsulation. The L2TPv3 Control Plane defined in RFC3931 is not used”. This suggests(at least to me)
that the management plane is involved just in setting up and tearing down a keyed IPv6 tunnel – similar to how static PWs over MPLS PSN are operated.
The catch comes with the last sentence of Section 3: “Cookie values SHOULD be changed
periodically” thus indicating that continuous intervention of the management entity is expected for the entire life cycle of the service – something that strongly smells of Lifecycle Service Orchestration (LSO)
to me, even if the term is never mentioned.
In the process of preparing this review I have sent my comments to the authors, to Carlos (the draft shepherd) and to Mark (who is listed as a contributing author). I have received very useful feedback from them that
has helped me to understand both the draft and the nature of our disagreements. I would like to thank Giles, Rayner, Carlos and Mark for a very useful discussion, even if we did not reach an agreement on some of the points yet.
Specification of encapsulation of Ethernet frames in Section 4 of the draft is incomplete and, to some extent, contradictory:
L2TPv3 L2-specific sublayer defined in RFC 3931 is not mentioned anywhere in the text.
As the draft borrows encapsulation of Ethernet frames from RFC 4719, one could expect that its usage is OPTIONAL (same as in RFC 4719)
On the other hand, L2-specific sublayer does not appear in the diagram depicting the encapsulation on page 5, so one could easily assume that it cannot be used
with keyed IPv6 tunnels
To add to this confusion, the draft mentions ability to use VCCV in a keyed IPv6 tunnel (Section 6, last para), and references RFC 5085. But this RFC, in Section
6.1 states that “In order to carry VCCV messages within an L2TPv3 session data packet, the PW MUST be established such that an L2-Specific Sublayer (L2SS) that defines the V-bit is
From my POV the authors must clearly and unequivocally specify whether L2-specific sublayer can or cannot be used in keyed IPv6 tunnels. If they decide that it cannot
be used, the references to VCCV must be removed from the draft.
I believe that this gap is acknowledged by the document shepherd and by one of the authors.
The draft does not explain the motivation for replacing the mechanism defined in RFC 4791 (which, AFAIK, was supposed to work equally well over IPv4 and IPv6).
I can guess that bypassing processing of Session ID simplifies the data plane processing, but this is just my guess. Some text explaining the benefits of keyed IPv6 tunnels in comparison with RFC 4719 would be most helpful IMO.
To the best of my understanding, the technology defined in the draft heavily depends on availability of an external management
entity that not only sets up and tears down the service (as is common with services that uses statically configured PWs, say, in MPLS-TP), but also intervenes in the operation of the service during its entire life cycle. However, the authors do not spell out
their expectations from such an entity, the only exception being the need to periodically change the cookie values in a coordinated manner. I do not expect the draft to provide a detailed specification of such an entity, but I think that both the implementers
and operators planning to deploy this technology would benefit from some additional information. In particular, the following aspects of behavior of the service that uses keyed IPv6 tunnels could be of special interest:
What happens to a P2P service that uses a keyed IPv6 tunnel to connect two Ethernet L2 circuits if failure of one of these circuits
is detected (e.g., using Ethernet service CFM between the Down MEP at the tunnel endpoint and a matching MEP in the CE as defined in Section 6, the first bullet on page 8)? Is transmission across the IPv6 PSN at the other endpoint expected to be throttled
by the management entity?
The possibility to use an anycast address for identification of a keyed IPv6 tunnel endpoint is mentioned twice in the draft
- in Section 2, 3rd para and in Section 4, first bullet on page 6. What happens if an anycast address assigned to one of the endpoints of a keyed IPv6 tunnel moves across the network? Is the management entity expected to handle these transitions,
say, by de-activating the former endpoint associated with an anycast address and activating the new one?
Is the management entity expected to emulate the PW redundancy mechanisms (defined in RFC 67180 and RFC 6870 for PWs over an
MPLS PSN and in RFC 5641 for the PWs using L2TPv3? It should be noted that, in the case of MPLS PWs, PW redundancy switchover does not require involvement of a management entity even for statically configured PWs. Instead, static PW status messages (RFC 6478)
The draft mentions the possibility to use keyed IPv6 tunnels to connect VSI participating in an MP2MP Ethernet service (even
if the term VSI is never used). To me this implies that local FIB in each of the VSI connected over keyed IPv6 tunnels would use MAC learning to populate its local FIB. In order to speed up convergence of such services following various external events, RFC
4672 introduces a dedicated mechanism for MAC withdrawal, and the PALS WG currently holds a WG item extending this functionality for VPLS services that use static PWs. Is the management entity expected to provide similar functionality as well? (It should be
noted that MAC withdrawal mechanisms have been defined as OPTIONAL in RFC 4762, but, AFAIK, they are widely implemented and deployed in the field).
The draft mentions (in many places) that it expects consistent configuration of the endpoints of a keyed IPv6 tunnel. However,
the draft (probably following a similar omission in RFC 4719) never mentions whether the management entity should prevent setting up a keyed IPv6 tunnel between a pair of endpoints with different MTU of L2 circuits. (This is a clear-cut requirement in RFC
4448 for Ethernet PWs over an MPLS PSN, and a parallel requirement for PWs over L2TPv3 can be found in RFC 4667). A short statement and a reference to RFC 4667 (missing in RFC 4719) would suffice IMO,
As mentioned before, the draft de-facto assigns IPv6 addresses to access-side L2 circuits that are not IP interfaces (the draft uses the term
“mapping”, but I do not see any difference). The draft RECOMMENDS (in para 2 of Section 2) that “local IPv6 addresses identifying L2TPv3 tunnels are assigned
from dedicated subnets used only for such tunnel endpoints”. From my POV this requirement is vague and the readers could benefit from clarification of associated issues. Again, I do not expect a detailed
specification, but I would like to see the some answers to the following naïve questions:
Is an IPv6 address identifying an endpoint of a keyed IPv6 tunnel that is associated with a L2 circuit expected to remain reachable if the L2 circuit to which
it is associated fails?
Are addresses (or subnets) used for identification of endpoints of keyed IPv6 tunnels expected to be exposed beyond the boundaries of the management domain controlled
by the above-mentioned management entity? Could they appear in the public Internet routing tables?
The draft says (Section 2, 3rd para) that “Certain deployment scenarios may
require using a single IPv6 address (typically a globally routable unicast or anycast address assigned to a virtual interface) to identify a tunnel endpoint for multiple IPv6 L2TPv3 tunnels. For such cases the tunnel encapsulating device identifies each
tunnel by a unique combination of local and remote IPv6 addresses”. From my POV the readers would benefit from the following clarifications:
What exactly “a globally routable address”
means in this context?
How, from the point of view of network reachability, are IPv6 addresses used in this scenario different from IPv6 addresses used to identify L2 circuits in other
Since the text mentions identification of the tunnel by an “encapsulation device”,
how is the tunnel identified by the decapsulating device? At least from the POV of MAC learning in the case of keyed IPv6 tunnels connecting VSI, identification of the tunnel by the decapsulating device seems more relevant to me
How should the device know whether a specific keyed IPv6 tunnel can be identified by just one IPv6 address or by a “a
unique combination of local and remote IPv6 addresses”?
As I have mentioned above, some details pertaining to the management functionality associated with keyed IPv6 tunnels are defined in another L2TPEXT WG draft, but this draft is not
mentioned in the draft I am reviewing. I think that an Informative reference to this draft would be very much in place in this one.
I wonder whether an Informative reference to a long (13-Jan-1999 according to the Datatracker) expired
draft of a concluded WG in the last sentence on page 3 has any value for the reader. If the ideas of this draft have found their way to some RFC, it should be used as a reference instead;
otherwise I believe that this reference cold be safely removed.
Some of the issues I have raised could be addressed in a suitable Applicability Statement section, but there are clearly other ways to handle them.
I (or, rather, my spellchecker) has found two typos:
Section 2, para 2:
Section 5, para 3 on page 7:
Email: Alexander.Vainshtein <at> ecitele.com