Re: RTG-DIR review: draft-ietf-l2tpext-keyed-ipv6-tunnel-05
"Carlos Pignataro (cpignata)" <[email protected]> Thu, 15 Oct 2015 19:21:18 +0000
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
--===============7480883691753459753== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A"; protocol="application/pgp-signature"; micalg=pgp-sha256 --Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A Content-Type: multipart/alternative; boundary="Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447" --Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Deborah, Authors of draft-ietf-l2tpext-keyed-ipv6-tunnel, Following up on this email =E2=80=94 who has the token on the next step? Authors, should you answer Sasha=E2=80=99s review? Thanks, =E2=80=94 Carlos. > On Sep 18, 2015, at 1:34 PM, [email protected] wrote: >=20 > 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, 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 = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir = <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. >=20 > Document: draft-ietf-l2tpext-keyed-ipv6-tunnel-05txt > Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein > Review Date: 18-Sep-15 > IETF LC End Date: Not Known > Intended Status: Proposed Standard >=20 > Caveat: > 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=E2=80=99d like to ask = the Routing ADs to take my comments with a big grain of salt. >=20 > Summary: > 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. >=20 > Comments: > As I see it, the draft is built around three key ideas: > 1. 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). > 2. 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. > 3. 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. >=20 > The term =E2=80=9Ckeyed IPv6 tunnel=E2=80=9D 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. >=20 > 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 = <https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-v6-tunnel-yang/= ?include_text=3D1> draft. >=20 > 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: > =C2=B7 The first sentence in Section 2 states that =E2=80=9CStat= ic 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=E2=80=9D. This suggests(at least to me) that the = management plane is involved just in setting up and tearing down a keyed = IPv6 tunnel =E2=80=93 similar to how static PWs over MPLS PSN are = operated. >=20 > =C2=B7 The catch comes with the last sentence of Section 3: = =E2=80=9CCookie values SHOULD be changed periodically=E2=80=9D thus = indicating that continuous intervention of the management entity is = expected for the entire life cycle of the service =E2=80=93 something = that strongly smells of Lifecycle Service Orchestration (LSO) to me, = even if the term is never mentioned. >=20 > 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. >=20 > Major Issue: > Specification of encapsulation of Ethernet frames in Section 4 of the = draft is incomplete and, to some extent, contradictory: > 1. L2TPv3 L2-specific sublayer defined in RFC 3931 is not = mentioned anywhere in the text. > 2. As the draft borrows encapsulation of Ethernet frames from RFC = 4719, one could expect that its usage is OPTIONAL (same as in RFC 4719) > 3. 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 >=20 > 4. 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 =E2=80=9CIn 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 present=E2=80=9D >=20 > =46rom 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. >=20 > I believe that this gap is acknowledged by the document shepherd and = by one of the authors. >=20 > Minor Issues: >=20 > 1. 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. > 2. 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: > a. 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? > b. 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? > c. 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) are used > d. 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). > 3. 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, > 4. 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 =E2=80=9Cmapping=E2=80=9D, but I do not see any difference). = The draft RECOMMENDS (in para 2 of Section 2) that =E2=80=9Clocal IPv6 = addresses identifying L2TPv3 tunnels are assigned from dedicated = subnets used only for such tunnel endpoints=E2=80=9D. =46rom 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=C3=AFve = questions: > a. 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? > b. 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? > 5. The draft says (Section 2, 3rd para) that =E2=80=9CCertain = 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=E2=80=9D. =46rom my POV the readers would benefit from the = following clarifications: > a. What exactly =E2=80=9Ca globally routable address=E2=80=9D = means in this context? > b. 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 deployment scenarios? > c. Since the text mentions identification of the tunnel by an = =E2=80=9Cencapsulation device=E2=80=9D, 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 > d. How should the device know whether a specific keyed IPv6 = tunnel can be identified by just one IPv6 address or by a =E2=80=9Ca = unique combination of local and remote IPv6 addresses=E2=80=9D? > 6. 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. > 7. I wonder whether an Informative reference to a long = (13-Jan-1999 according to the Datatracker) expired draft = <https://datatracker.ietf.org/doc/draft-ietf-pppext-l2tphc/> 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. >=20 > 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. >=20 > Nits: > I (or, rather, my spellchecker) has found two typos: > =C2=B7 Section 2, para 2: s/endponts/endpoints/ > =C2=B7 Section 5, para 3 on page 7: = s/Fragmention/Fragmentation/ >=20 > Regards, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: [email protected] = <mailto:[email protected]> >=20 > _______________________________________________ > L2tpext mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/l2tpext = <https://www.ietf.org/mailman/listinfo/l2tpext> --Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Deborah, Authors of draft-ietf-l2tpext-keyed-ipv6-tunnel,<div = class=3D""><br class=3D""></div><div class=3D"">Following up on this = email =E2=80=94 who has the token on the next step?</div><div = class=3D""><br class=3D""></div><div class=3D"">Authors, should you = answer Sasha=E2=80=99s review?</div><div class=3D""><br = class=3D""></div><div class=3D"">Thanks,</div><div class=3D""><br = class=3D""></div><div class=3D"">=E2=80=94 Carlos.</div><div = class=3D""><br class=3D""></div><div class=3D""><br = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = Sep 18, 2015, at 1:34 PM, <a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"WordSection1" style=3D"page: WordSection1; font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div = style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif;" class=3D"">Hello,<o:p class=3D""></o:p></div><div = style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times = New Roman', serif; background-color: white;" class=3D""><span = class=3D"apple-converted-space"><span style=3D"font-size: 11pt;" = class=3D"">I </span></span><span style=3D"font-size: 11pt;" = class=3D"">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<span = class=3D"apple-converted-space"> </span><a = href=3D"http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir" = style=3D"color: purple; text-decoration: underline;" class=3D""><span = class=3D"icon"><span style=3D"color: rgb(68, 0, 136);" = class=3D"">=E2=80=8B</span></span><span style=3D"font-size: 12pt; color: = rgb(68, 0, 136);" = class=3D"">http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir</span></a>= <o:p class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white; orphans: auto; text-align: start; widows: 1; = -webkit-text-stroke-width: 0px; word-spacing: 0px;" class=3D""><span = style=3D"font-size: 11pt;" class=3D"">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.<o:p class=3D""></o:p></span></div><div = style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times = New Roman', serif; background-color: white;" class=3D""><span = style=3D"font-size: 11pt;" class=3D""><o:p = class=3D""> </o:p></span></div><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white; orphans: auto; text-align: start; widows: 1; = -webkit-text-stroke-width: 0px; word-spacing: 0px;" class=3D""><span = style=3D"font-size: 11pt;" class=3D"">Document:<span = class=3D"apple-converted-space"> </span>draft-ietf-l2tpext-keyed-ipv6= -tunnel-05txt<span class=3D"apple-converted-space"> </span><br = class=3D"">Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein<br = class=3D"">Review Date: 18-Sep-15<br class=3D"">IETF LC End Date: Not = Known<span class=3D"apple-converted-space"> </span><br = class=3D"">Intended Status: Proposed Standard<o:p = class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; = font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white; orphans: auto; text-align: start; widows: 1; = -webkit-text-stroke-width: 0px; word-spacing: 0px;" class=3D""><strong = class=3D""><o:p class=3D""> </o:p></strong></div><div = style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times = New Roman', serif; background-color: white;" class=3D""><strong = class=3D""><span style=3D"font-size: 11pt;" class=3D"">Caveat:<o:p = class=3D""></o:p></span></strong></div><p style=3D"margin-right: 0cm; = margin-left: 36pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D"">I am = not an IPv6 expert and this can be the reason for some of my concerns = about the draft.</span><o:p class=3D""></o:p></p><p style=3D"margin-right:= 0cm; margin-left: 36pt; font-size: 12pt; font-family: 'Times New = Roman', serif; margin-bottom: 0.0001pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D"">My = experience with L2TPv3 is also outdated. So I=E2=80=99d like to ask the = Routing ADs to take my comments with a big grain of salt.<o:p = class=3D""></o:p></span></p><div style=3D"margin: 0cm 0cm 0.0001pt; = font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white;" class=3D""><strong class=3D""><o:p = class=3D""> </o:p></strong></div><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white;" class=3D""><strong class=3D""><span = style=3D"font-size: 11pt;" class=3D"">Summary:</span></strong><span = class=3D"apple-converted-space"><span style=3D"font-size: 11pt;" = class=3D""> </span><o:p class=3D""></o:p></span></div><p = style=3D"margin-right: 0cm; margin-left: 36pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D"">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.<o:p class=3D""></o:p></span></p><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white;" class=3D""><strong class=3D""><o:p = class=3D""> </o:p></strong></div><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white;" class=3D""><strong class=3D""><span = style=3D"font-size: 11pt;" class=3D"">Comments:</span><o:p = class=3D""></o:p></strong></div><p style=3D"margin-right: 0cm; = margin-left: 36pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D"">As I = see it, the draft is built around three key ideas:<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 75.15pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">1.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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).<span = class=3D"Apple-converted-space"> </span><o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 75.15pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">2.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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.<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 75.15pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">3.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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.<o:p class=3D""></o:p></span></p><p = style=3D"margin-right: 0cm; margin-left: 36pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D""><o:p class=3D""> </o:p></span></p><p = style=3D"margin-right: 0cm; margin-left: 36pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D"">The term =E2=80=9Ckeyed IPv6 tunnel=E2=80=9D 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.<o:p class=3D""></o:p></span></p><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white;" class=3D""><span style=3D"font-size: 11pt;" = class=3D""><o:p class=3D""> </o:p></span></div><p = style=3D"margin-right: 0cm; margin-left: 36pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D"">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<span = class=3D"Apple-converted-space"> </span><a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-v6-tunne= l-yang/?include_text=3D1" style=3D"color: purple; text-decoration: = underline;" class=3D"">YANG Data Model</a><span = class=3D"Apple-converted-space"> </span>draft.<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 36pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt;" class=3D""><o:p = class=3D""> </o:p></span></p><p style=3D"margin-right: 0cm; = margin-left: 36pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D"">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.</span><span style=3D"font-size: 11pt; font-family: 'Courier = New';" class=3D""><span = class=3D"Apple-converted-space"> </span></span><span = style=3D"font-size: 11pt;" class=3D"">One example illustrating this = complaint:<o:p class=3D""></o:p></span></p><p style=3D"margin-right: = 0cm; margin-left: 72pt; font-size: 12pt; font-family: 'Times New Roman', = serif; text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt; font-family: Symbol;" class=3D""><span = class=3D"">=C2=B7<span style=3D"font-style: normal; font-variant: = normal; font-weight: normal; font-size: 7pt; line-height: normal; = font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">The first sentence in Section 2 states that =E2=80=9C</span><sp= an style=3D"font-size: 11pt; font-family: 'Courier New';" = class=3D"">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</span><span style=3D"font-size: = 11pt;" class=3D"">=E2=80=9D. This suggests(at least to me) that the = management plane is involved just in setting up and tearing down a keyed = IPv6 tunnel =E2=80=93 similar to how static PWs over MPLS PSN are = operated.<o:p class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; = margin-left: 72pt; font-size: 12pt; font-family: 'Times New Roman', = serif; text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt; font-family: Symbol;" class=3D""><span = class=3D"">=C2=B7<span style=3D"font-style: normal; font-variant: = normal; font-weight: normal; font-size: 7pt; line-height: normal; = font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">The catch comes with the last sentence of Section 3: = =E2=80=9C</span><span style=3D"font-size: 11pt; font-family: 'Courier = New';" class=3D"">Cookie values SHOULD be changed = periodically</span><span style=3D"font-size: 11pt;" class=3D"">=E2=80=9D = thus indicating that continuous intervention of the management entity is = expected for the entire life cycle of the service =E2=80=93 something = that strongly smells of Lifecycle Service Orchestration (LSO) to me, = even if the term is never mentioned.<o:p class=3D""></o:p></span></p><p = style=3D"margin-right: 0cm; margin-left: 36pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D"">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.<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 36pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt;" class=3D""><o:p = class=3D""> </o:p></span></p><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white;" class=3D""><strong class=3D""><span = style=3D"font-size: 11pt;" class=3D"">Major Issue:</span><o:p = class=3D""></o:p></strong></div><p style=3D"margin-right: 0cm; = margin-left: 54pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" = class=3D"">Specification of encapsulation of Ethernet frames in Section = 4 of the draft is incomplete and, to some extent, contradictory:<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 90pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">1.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">L2TPv3 L2-specific sublayer defined in RFC 3931 is not = mentioned anywhere in the text.<o:p class=3D""></o:p></span></p><p = style=3D"margin-right: 0cm; margin-left: 90pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt;" class=3D""><span class=3D"">2.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">As the draft borrows encapsulation of Ethernet frames from = RFC 4719, one could expect that its usage is OPTIONAL (same as in RFC = 4719)<o:p class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; = margin-left: 90pt; font-size: 12pt; font-family: 'Times New Roman', = serif; text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt;" class=3D""><span class=3D"">3.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 90pt; font-size: 12pt; font-family: 'Times New Roman', serif; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt;" class=3D""><span class=3D"">4.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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 =E2=80=9C</span><span = style=3D"font-size: 11pt; font-family: 'Courier New';" class=3D"">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 present</span><span style=3D"font-size: 11pt;" = class=3D"">=E2=80=9D<o:p class=3D""></o:p></span></p><p = style=3D"margin-right: 0cm; margin-left: 54pt; font-size: 12pt; = font-family: 'Times New Roman', serif; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D"">=46rom = 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.<span = class=3D"Apple-converted-space"> </span><o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 54pt; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D"">I believe that this gap is acknowledged by the = document shepherd and by one of the authors.<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 0cm; font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" = class=3D""> &nb= sp; <span = class=3D"Apple-converted-space"> </span><strong class=3D"">Minor = Issues:</strong><o:p class=3D""></o:p></span></p><p style=3D"margin-right:= 0cm; margin-left: 72pt; font-size: 12pt; font-family: 'Times New = Roman', serif; margin-bottom: 0.0001pt; text-indent: -18pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D""><span class=3D"">1.<span style=3D"font-style: normal; = font-variant: normal; font-weight: normal; font-size: 7pt; line-height: = normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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.<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 72pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><strong class=3D""><span style=3D"font-weight: = normal;" class=3D""><span class=3D"">2.<span style=3D"font-style: = normal; font-variant: normal; font-weight: normal; font-size: 7pt; = line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span></strong= ><span dir=3D"LTR" class=3D""></span><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D"">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:</span></strong><strong class=3D""><span style=3D"font-weight: = normal;" class=3D""><o:p class=3D""></o:p></span></strong></p><p = style=3D"margin-right: 0cm; margin-left: 108pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><strong = class=3D""><span style=3D"font-size: 11pt; font-weight: normal;" = class=3D""><span class=3D"">a.<span style=3D"font-style: normal; = font-variant: normal; font-weight: normal; font-size: 7pt; line-height: = normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span></strong= ><span dir=3D"LTR" class=3D""></span><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D"">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?<span = class=3D"Apple-converted-space"> </span><o:p = class=3D""></o:p></span></strong></p><p style=3D"margin-right: 0cm; = margin-left: 108pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; text-indent: -18pt; background-color: = white; background-position: initial initial; background-repeat: initial = initial;" class=3D""><strong class=3D""><span style=3D"font-size: 11pt; = font-weight: normal;" class=3D""><span class=3D"">b.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span></strong= ><span dir=3D"LTR" class=3D""></span><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D"">The = possibility to use an anycast address for identification of a keyed IPv6 = tunnel endpoint is mentioned twice in the draft - in Section 2, 3<sup = class=3D"">rd</sup><span class=3D"Apple-converted-space"> </span>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?<o:p = class=3D""></o:p></span></strong></p><p style=3D"margin-right: 0cm; = margin-left: 108pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; text-indent: -18pt; background-color: = white; background-position: initial initial; background-repeat: initial = initial;" class=3D""><strong class=3D""><span style=3D"font-size: 11pt; = font-weight: normal;" class=3D""><span class=3D"">c.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span></strong= ><span dir=3D"LTR" class=3D""></span><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D"">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) are used<o:p = class=3D""></o:p></span></strong></p><p style=3D"margin-right: 0cm; = margin-left: 108pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; text-indent: -18pt; background-color: = white; background-position: initial initial; background-repeat: initial = initial;" class=3D""><strong class=3D""><span style=3D"font-size: 11pt; = font-weight: normal;" class=3D""><span class=3D"">d.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span></strong= ><span dir=3D"LTR" class=3D""></span><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D"">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).<o:p class=3D""></o:p></span></strong></p><p style=3D"margin-right:= 0cm; margin-left: 72pt; font-size: 12pt; font-family: 'Times New = Roman', serif; margin-bottom: 0.0001pt; text-indent: -18pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D""><span = class=3D"">3.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span></strong= ><span dir=3D"LTR" class=3D""></span><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D"">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,<o:p class=3D""></o:p></span></strong></p><p = style=3D"margin-right: 0cm; margin-left: 72pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = class=3D"">4.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span><span = dir=3D"LTR" class=3D""></span><strong class=3D""><span style=3D"font-size:= 11pt; font-weight: normal;" class=3D"">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 =E2=80=9Cmapping=E2=80=9D, but I = do not see any difference). The draft RECOMMENDS (in para 2 of Section = 2) that =E2=80=9C</span></strong><span style=3D"font-size: 11pt; = font-family: 'Courier New';" class=3D"">l<span style=3D"" class=3D"">ocal = IPv6 addresses identifying L2TPv3 tunnels are assigned from = dedicated subnets used only for such tunnel endpoints</span></span><span = style=3D"font-size: 11pt;" class=3D"">=E2=80=9D. =46rom 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=C3=AFve = questions:</span><o:p class=3D""></o:p></p><p style=3D"margin-right: = 0cm; margin-left: 108pt; font-size: 12pt; font-family: 'Times New = Roman', serif; margin-bottom: 0.0001pt; text-indent: -18pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D""><span class=3D"">a.<span style=3D"font-style: normal; = font-variant: normal; font-weight: normal; font-size: 7pt; line-height: = normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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?<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 108pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">b.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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?<o:p class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; = margin-left: 72pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; text-indent: -18pt; background-color: = white; background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">5.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">The draft says (Section 2, 3<sup class=3D"">rd</sup><span = class=3D"Apple-converted-space"> </span>para) that =E2=80=9C</span><s= pan style=3D"font-size: 11pt; font-family: 'Courier New';" = class=3D"">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</span><span style=3D"font-size: 11pt;" class=3D"">=E2=80=9D. = =46rom my POV the readers would benefit from the following = clarifications:<o:p class=3D""></o:p></span></p><p style=3D"margin-right: = 0cm; margin-left: 108pt; font-size: 12pt; font-family: 'Times New = Roman', serif; margin-bottom: 0.0001pt; text-indent: -18pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D""><span class=3D"">a.<span style=3D"font-style: normal; = font-variant: normal; font-weight: normal; font-size: 7pt; line-height: = normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">What exactly =E2=80=9C</span><span style=3D"font-size: 11pt; = font-family: 'Courier New';" class=3D"">a globally routable = address</span><span style=3D"font-size: 11pt;" class=3D"">=E2=80=9D = means in this context?<o:p class=3D""></o:p></span></p><p = style=3D"margin-right: 0cm; margin-left: 108pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-size: 11pt;" class=3D""><span class=3D"">b.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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 deployment scenarios?<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 108pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">c.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">Since the text mentions identification of the tunnel by an = =E2=80=9C</span><span style=3D"font-size: 11pt; font-family: 'Courier = New';" class=3D"">encapsulation device</span><span style=3D"font-size: = 11pt;" class=3D"">=E2=80=9D, 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<o:p = class=3D""></o:p></span></p><p style=3D"margin-right: 0cm; margin-left: = 108pt; font-size: 12pt; font-family: 'Times New Roman', serif; = margin-bottom: 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><span style=3D"font-size: 11pt;" class=3D""><span = class=3D"">d.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">How should the device know whether a specific keyed = IPv6 tunnel can be identified by just one IPv6 address or by a = =E2=80=9C</span><span style=3D"font-size: 11pt; font-family: 'Courier = New';" class=3D"">a unique combination of local and remote = IPv6 addresses</span><span style=3D"font-size: 11pt;" = class=3D"">=E2=80=9D?<o:p class=3D""></o:p></span></p><p = style=3D"margin-right: 0cm; margin-left: 72pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = class=3D"">6.<span style=3D"font-style: normal; font-variant: normal; = font-weight: normal; font-size: 7pt; line-height: normal; font-family: = 'Times New Roman';" class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span><span = dir=3D"LTR" class=3D""></span><span style=3D"font-size: 11pt;" = class=3D"">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</span>. <span = class=3D"Apple-converted-space"> </span><span style=3D"font-size: = 11pt;" class=3D"">I think that an Informative reference to this draft = would be very much in place in this one.</span><o:p = class=3D""></o:p></p><p style=3D"margin-right: 0cm; margin-left: 72pt; = font-size: 12pt; font-family: 'Times New Roman', serif; margin-bottom: = 0.0001pt; text-indent: -18pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><strong class=3D""><span style=3D"font-size: 11pt; = font-weight: normal;" class=3D""><span class=3D"">7.<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span></strong= ><span dir=3D"LTR" class=3D""></span><strong class=3D""><span = style=3D"font-size: 11pt; font-weight: normal;" class=3D"">I wonder = whether an Informative reference to a long (13-Jan-1999 according to the = Datatracker) expired<span class=3D"Apple-converted-space"> </span><a = href=3D"https://datatracker.ietf.org/doc/draft-ietf-pppext-l2tphc/" = style=3D"color: purple; text-decoration: underline;" = class=3D"">draft</a><span class=3D"Apple-converted-space"> </span>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.<o:p = class=3D""></o:p></span></strong></p><p style=3D"margin-right: 0cm; = margin-left: 36pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><o:p class=3D""> </o:p></p><p = style=3D"margin-right: 0cm; margin-left: 36pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = background-color: white; background-position: initial initial; = background-repeat: initial initial;" class=3D""><span style=3D"font-size: = 11pt;" class=3D"">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.<o:p class=3D""></o:p></span></p><div style=3D"margin:= 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', = serif; background-color: white;" class=3D""><o:p = class=3D""> </o:p></div><div style=3D"margin: 0cm 0cm 0.0001pt; = font-size: 12pt; font-family: 'Times New Roman', serif; = background-color: white;" class=3D""><strong class=3D""><span = style=3D"font-size: 11pt;" class=3D"">Nits:<o:p = class=3D""></o:p></span></strong></div><p style=3D"margin-right: 0cm; = margin-left: 36pt; font-size: 12pt; font-family: 'Times New Roman', = serif; margin-bottom: 0.0001pt; background-color: white; = background-position: initial initial; background-repeat: initial = initial;" class=3D""><strong class=3D""><span style=3D"font-size: 11pt; = font-weight: normal;" class=3D"">I (or, rather, my spellchecker) has = found two typos:<o:p class=3D""></o:p></span></strong></p><p = style=3D"margin-right: 0cm; margin-left: 72pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-family: Symbol;" class=3D""><span class=3D"">=C2=B7<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><strong class=3D""><span style=3D"font-size:= 11pt; font-weight: normal;" class=3D"">Section 2, para 2:<span = class=3D"Apple-converted-space"> </span></span></strong><span = style=3D"font-size: 10.5pt; font-family: 'Courier New';" = class=3D"">s/endponts/endpoints/</span><o:p class=3D""></o:p></p><p = style=3D"margin-right: 0cm; margin-left: 72pt; font-size: 12pt; = font-family: 'Times New Roman', serif; margin-bottom: 0.0001pt; = text-indent: -18pt; background-color: white; background-position: = initial initial; background-repeat: initial initial;" class=3D""><span = style=3D"font-family: Symbol;" class=3D""><span class=3D"">=C2=B7<span = style=3D"font-style: normal; font-variant: normal; font-weight: normal; = font-size: 7pt; line-height: normal; font-family: 'Times New Roman';" = class=3D""> <span = class=3D"Apple-converted-space"> </span></span></span></span><span = dir=3D"LTR" class=3D""></span><strong class=3D""><span style=3D"font-size:= 11pt; font-weight: normal;" class=3D"">Section 5, para 3 on page = 7: <span = class=3D"Apple-converted-space"> </span></span></strong><span = style=3D"font-size: 10.5pt; font-family: 'Courier New';" = class=3D"">s/Fragmention/Fragmentation/</span><o:p = class=3D""></o:p></p><div style=3D"margin: 0cm 0cm 0.0001pt; font-size: = 12pt; font-family: 'Times New Roman', serif; background-color: white;" = class=3D""><span style=3D"font-family: Calibri, sans-serif;" = class=3D""><o:p class=3D""> </o:p></span></div><div style=3D"margin: = 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">Regards,<o:p class=3D""></o:p></div><div style=3D"margin: 0cm = 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">Sasha<o:p class=3D""></o:p></div><div style=3D"margin: 0cm = 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D""><o:p class=3D""> </o:p></div><div style=3D"margin: 0cm = 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">Office: +972-39266302<o:p class=3D""></o:p></div><div = style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif;" class=3D"">Cell: = +972-549266302<o:p class=3D""></o:p></div><div style=3D"margin: 0cm 0cm = 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" = class=3D"">Email: <span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:[email protected]" style=3D"color: purple; = text-decoration: underline;" = class=3D"">[email protected]</a><o:p = class=3D""></o:p></div><div style=3D"margin: 0cm 0cm 0.0001pt; = font-size: 11pt; font-family: Calibri, sans-serif;" class=3D""><o:p = class=3D""> </o:p></div></div><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" = class=3D"">_______________________________________________</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" class=3D"">L2tpext mailing = list</span><br style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"mailto:[email protected]" style=3D"color: purple; = text-decoration: underline; font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D"">[email protected]</a><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"https://www.ietf.org/mailman/listinfo/l2tpext" style=3D"color: = purple; text-decoration: underline; font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D"">https://www.ietf.org/mailman/listinfo/l2tpext</a></div></blockq= uote></div><br class=3D""></div></body></html>= --Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447-- --Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWH/y4AAoJEIXgpQGOZny9Dr0P/jWDlDk69LGFIjfouiHv8xYh Tunbn5O2NRcYSXdv8nda1s+L5Wuik5ErYYQcQc0zq6zkhi1dEnfGe3rJsVNLxp/6 5ssjSQxqRSvGHrUrhSIhzLV+3yJyqjuod2AwAla6k6i//oCB/0q6gRwgLDKQ0wFK hN0Yp/8k0OJUOssrcpQw3PnwzI/eXxGdMSalerYssxTbv8Ley8/j+YZ0CWpT0s9B 7sG3qY3UGyw8pIMnhSKklLtnJ6utjsEoQ6TkR+S4uprfwPc6TcECzSaM/1MJ49lP jUFA/bu5w5ZIzOM7uxwuxJNYAedFgt6aeREjOCCC/MchpbXxVkAJ+eiLOsLZaJIT zkjVtrUBBwyKxPX88qRLbtsnHPaWoN0LaQsxWrpMKgg0pWL4wxhI36lFQHoOhYjy 0NCDTf5yqcStdgZDTABhPJogAJjAjJoRQsJA5QqCP8IYKRkqJSSvqWt77K4wmTpZ Ck+I8Z+P4ae3vx6eo7zp8iiKhmlodJBDlFVmgoD+vZLzIxws/VmlVfGMMd270rXI kN/Cc55iHcF5jTxb3iGUC3VPIuMLJALw4qzf2B9n7IyAKoHLc8a10zo1TsrHMnba KVq6F9FdB3R+HoPkHgDqGd9vmLirUB3Ivto3YoivSEudxislnCZwAtIVGKZLbgAb MLaKY7/6hac2S5b5hBze =Vz9k -----END PGP SIGNATURE----- --Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A-- --===============7480883691753459753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2tpext mailing list [email protected] https://www.ietf.org/mailman/listinfo/l2tpext --===============7480883691753459753==--