Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 5 Jun 2017 12:37:27 +0000

I support this draft.

Also, this draft defines the Tunnel Encapsulation Attribute for which a new tunnel type (SR Policy) has been defined, as well as additional TLVs, by draft-previdi-idr-segment-routing-te-policy and for which we have an implementation.

s.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of John G. Scudder
> Sent: Saturday, May 20, 2017 3:47 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
> 
> Hi All,
> 
> A working group last call has been requested for draft-ietf-idr-tunnel-encaps-04.
> Please reply to the list with your comments. As usual note we cannot advance
> the draft without participation from the group. Please get your comments in
> before June 5, 2017.
> 
> Authors, please confirm that any relevant IPR has been disclosed.
> 
> https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04
> 
> Thanks,
> 
> --John
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 9 Jun 2017 14:16:59 -0400

Hi All,

At present we don't have demonstrated consensus to advance the document. Other than the three authors (whose support can be assumed unless they disclaim it, as far as I'm concerned, so there's really no need for "support as co-author" statements, thanks for not sending them!) I count two people (John D and Stefano P) who unequivocally support advancement, one (Lou B) who does "but after addressing some comments" (which haven't yet been addressed) and one (Job S) who is opposed until implementation experience is documented. Xiaohu also provided a comment which I take to be a request to update the document, Randy commented on the thread but without taking a position.

Given both the number of points surfaced (primarily though not only in the extended exchange between Eric and Lou) and the small number of WG members who responded, I think we can't advance the document yet.

What follows is a wall of text (sorry) where I try to capture the open items arising from the WGLC discussion. I'd like to suggest the authors (and in some cases, WG) address these, at which point we can retry the WGLC. If it turns out meeting time is needed in Prague for discussion, that's a possibility. 

I've taken the liberty of tagging suggested action items. Individuals "(AI: Eric)", "(AI: Lou)", "(AI: Acee)" should be obvious, I've also tagged some "(AI: WG)" where it seems to me that there's a fundamental disagreement between two people (all Lou and Eric, actually) and nobody else has weighed in. If these aren't resolved by further discussion prior to the next WGLC, you can expect them to be called out in the WGLC poll at that time, so that we can at least know that people have been made aware of the issue before they express their preference for document advancement. So for these, the AI to the WG is to review the discussion, understand the issue, and chime in as you see fit.

Thanks,

--John

WGLC summary
------------

Implementations
---------------

There was a request for reporting of implementations. 
- Job Snijders created a wiki stub (thanks!) to hold implementation reports, see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations. 
- Lou Berger reported a partial implementation (https://www.ietf.org/mail-archive/web/idr/current/msg18155.html). I added a link and quote to the wiki. 
- Acee commented (https://www.ietf.org/mail-archive/web/idr/current/msg18199.html) that "Cisco is supporting Tunnel Attribute parsing and propagation as well as the TE-Policy tunnel type in an unreleased version of IOS-XR" and promised to update the wiki, but hasn't yet. Acee, if you need help with that, please let me know. (AI: Acee)
- Eric commented (https://www.ietf.org/mail-archive/web/idr/current/msg18200.html) that "Juniper also has an implementation of various parts of the draft, as needed to support the segment-routing-te-policy draft.  Some other parts of the draft have also been implemented as well."
- Stefano said (https://www.ietf.org/mail-archive/web/idr/current/msg18225.html) "this draft defines the Tunnel Encapsulation Attribute for which a new tunnel type (SR Policy) has been defined, as well as additional TLVs, by draft-previdi-idr-segment-routing-te-policy and for which we have an implementation".

As Job correctly observed, IDR tradition doesn't strictly require implementations in order to complete WGLC, but it's perfectly reasonable for WG participants to predicate their support on implementation. Besides, since we do need implementation before sending the document to the IESG, we're going to need to clear this up no later than immediately following WGLC completion.

Given nobody has claimed anything other than "partial" support I think we have not heard the last of this question. Given the lack of enthusiasm for reporting implementation status, I don't feel optimistic that self-reporting will result in much detail. A volunteer to help produce a more structured implementation report would be great. If not, this will fall to the chairs to do or delegate as time allows.

Other Issues
------------

Xiaohu
------

Xiaohu commented (https://www.ietf.org/mail-archive/web/idr/current/msg18182.html) "Since the NVGRE header has a protocol field, it seems unnecessary to add the fake MAC header when encapsulating IP packets over NVGRE in the inter-subnet scenario, as described in (https://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-00#page-3)." 

Eric replied (https://www.ietf.org/mail-archive/web/idr/current/msg18205.html) "The intention of section 3.2.3 (NVGRE) in the tunnel encaps draft is to provide the encapsulation information that is needed to form an NVGRE encapsulation as specified in RFC 7637.  If I'm understanding correctly, the draft cited above is an extension to or modification of RFC 7637, but was never adopted.  Am I wrong about that?". Unless Xiaohu has more to say, I'm considering the issue closed.

Lou
---

Lou Berger opened a number of issues (https://www.ietf.org/mail-archive/web/idr/current/msg18155.html). Discussion of these dominated the WGLC. I tried to follow the discussion for each and summarize below. (The below is not a complete set of quotations, just headlines.)

"1. I think this document needs to cover its impact on RF5566."

After quite a long discussion, Eric agreed (https://www.ietf.org/mail-archive/web/idr/current/msg18203.html) to add the following, proposed by Lou:

> How about something adding something like the following to section 1
> 
>   RFC5566 uses the mechanisms defined in RFC5512, while this document replaces RFC5512
>   it does not address how the tunnel types defined in RFC5566 can be used with SAFIs other
>   than the Encapsulation SAFI.

"2. WRT the Encapsulation Extended Community.  I find the following rule
very hard to parse:"

There was a back-and-forth ending with a proposal from Lou (https://www.ietf.org/mail-archive/web/idr/current/msg18173.html modified by https://www.ietf.org/mail-archive/web/idr/current/msg18177.html, modified text shown):

> How about replacing the quoted paragraph with:
>  
>    An Encapsulation Extended Community MUST be included when a barebones
>    Tunnel TLV is used to identify a tunnel type. The corresponding
> barebones
>    Tunnel Encapsulation attribute MAY be omitted in this case.
> 
> BTW our implementation always includes a "barebones" Encapsulation
> Extended Community ;-)

I believe this ended with "Well we disagree." (https://www.ietf.org/mail-archive/web/idr/current/msg18195.html). The issue is open. (AI: WG)

"3. I'm not sure why the color sub-tlv is still needed. why not just use
the Color Extended Community alone?"

There was a long exchange on this with Lou taking the position that the ability to advertise multiple tunnel types in a single update represents unnecessary complexity and Eric taking the position that it's a reasonable optimization. Lou and Eric clearly understood each other's points but disagreed. Lou provided the caveat that if the mechanism is already being used then his objection is withdrawn, however nobody has said it's being used so presumably the objection stands.

The authors clearly don't believe a change is warranted, equally clearly Lou is unconvinced. The issue is open. (AI: WG)

There was a secondary point raised as part of the exchange (https://www.ietf.org/mail-archive/web/idr/current/msg18173.html), I will call this 3.a:

3.a. " If this is kept, it seems like there's some special aggregation rules
that could apply."

This ended with (https://www.ietf.org/mail-archive/web/idr/current/msg18203.html) "Since we don't currently know what policies might be needed by a future application, we can't specify them now." As far as I can tell this issue is closed.

"4. In section 12.4, values should be defined by this document of the
newly established Tunnel Encapsulation Attribute Sub-TLVs registry."

Back-and-forth, agreement to defer. FWIW, I concur that it's fine to specify values inline for a new registry (this is not OK for existing registries of course), although it's also acceptable to wait and have IANA do it if there's no pressing need.

"5. Nit: the document says "This document deprecates the Encapsulation
SAFI (which has never been used)".  The use part of this statement isn't
strictly true"

This stands at Lou agreeing it's OK to leave the text as is if desired, Eric asked Lou "Was there ever a production deployment? I'm sure the IESG will ultimately grill me on this, so I would like to get the facts right." I haven't seen a response from Lou on-list. (AI: Lou)

"(new issue 6) In looking at the google doc, I was reminded of a
deficiency of  in 5512 that still exists in the wg draft.  Neither ever
define the format of the Tunnel TLV." (added in https://www.ietf.org/mail-archive/web/idr/current/msg18173.html)

Eric responded that Figure 1 covers this, Lou agreed, issue closed.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 9 Jun 2017 19:42:08 +0000

Hi John, 

As the owner an AI, I support publication as well.

Thanks,
Acee 

On 6/9/17, 2:16 PM, "Idr on behalf of John G. Scudder"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi All,
>
>At present we don't have demonstrated consensus to advance the document.
>Other than the three authors (whose support can be assumed unless they
>disclaim it, as far as I'm concerned, so there's really no need for
>"support as co-author" statements, thanks for not sending them!) I count
>two people (John D and Stefano P) who unequivocally support advancement,
>one (Lou B) who does "but after addressing some comments" (which haven't
>yet been addressed) and one (Job S) who is opposed until implementation
>experience is documented. Xiaohu also provided a comment which I take to
>be a request to update the document, Randy commented on the thread but
>without taking a position.
>
>Given both the number of points surfaced (primarily though not only in
>the extended exchange between Eric and Lou) and the small number of WG
>members who responded, I think we can't advance the document yet.
>
>What follows is a wall of text (sorry) where I try to capture the open
>items arising from the WGLC discussion. I'd like to suggest the authors
>(and in some cases, WG) address these, at which point we can retry the
>WGLC. If it turns out meeting time is needed in Prague for discussion,
>that's a possibility.
>
>I've taken the liberty of tagging suggested action items. Individuals
>"(AI: Eric)", "(AI: Lou)", "(AI: Acee)" should be obvious, I've also
>tagged some "(AI: WG)" where it seems to me that there's a fundamental
>disagreement between two people (all Lou and Eric, actually) and nobody
>else has weighed in. If these aren't resolved by further discussion prior
>to the next WGLC, you can expect them to be called out in the WGLC poll
>at that time, so that we can at least know that people have been made
>aware of the issue before they express their preference for document
>advancement. So for these, the AI to the WG is to review the discussion,
>understand the issue, and chime in as you see fit.
>
>Thanks,
>
>--John
>
>
>WGLC summary
>------------
>
>Implementations
>---------------
>
>- Job Snijders created a wiki stub (thanks!) to hold implementation
>reports, see 
>https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20impleme
>ntations. 
>- Lou Berger reported a partial implementation
>(https://www.ietf.org/mail-archive/web/idr/current/msg18155.html). I
>added a link and quote to the wiki.
>- Acee commented 
>(https://www.ietf.org/mail-archive/web/idr/current/msg18199.html) that
>"Cisco is supporting Tunnel Attribute parsing and propagation as well as
>the TE-Policy tunnel type in an unreleased version of IOS-XR" and
>promised to update the wiki, but hasn't yet. Acee, if you need help with
>that, please let me know. (AI: Acee)
>- Eric commented 
>(https://www.ietf.org/mail-archive/web/idr/current/msg18200.html) that
>"Juniper also has an implementation of various parts of the draft, as
>needed to support the segment-routing-te-policy draft.  Some other parts
>of the draft have also been implemented as well."
>- Stefano said 
>(https://www.ietf.org/mail-archive/web/idr/current/msg18225.html) "this
>draft defines the Tunnel Encapsulation Attribute for which a new tunnel
>type (SR Policy) has been defined, as well as additional TLVs, by
>draft-previdi-idr-segment-routing-te-policy and for which we have an
>implementation".
>
>As Job correctly observed, IDR tradition doesn't strictly require
>implementations in order to complete WGLC, but it's perfectly reasonable
>for WG participants to predicate their support on implementation.
>Besides, since we do need implementation before sending the document to
>the IESG, we're going to need to clear this up no later than immediately
>following WGLC completion.
>
>Given nobody has claimed anything other than "partial" support I think we
>have not heard the last of this question. Given the lack of enthusiasm
>for reporting implementation status, I don't feel optimistic that
>self-reporting will result in much detail. A volunteer to help produce a
>more structured implementation report would be great. If not, this will
>fall to the chairs to do or delegate as time allows.
>
>Other Issues
>------------
>
>Xiaohu
>------
>
>Xiaohu commented 
>(https://www.ietf.org/mail-archive/web/idr/current/msg18182.html) "Since
>the NVGRE header has a protocol field, it seems unnecessary to add the
>fake MAC header when encapsulating IP packets over NVGRE in the
>inter-subnet scenario, as described in
>(https://tools.ietf.org/html/draft-yong-l3vpn-nvgre-vxlan-encap-00#page-3)
>." 
>
>Eric replied 
>(https://www.ietf.org/mail-archive/web/idr/current/msg18205.html) "The
>intention of section 3.2.3 (NVGRE) in the tunnel encaps draft is to
>provide the encapsulation information that is needed to form an NVGRE
>encapsulation as specified in RFC 7637.  If I'm understanding correctly,
>the draft cited above is an extension to or modification of RFC 7637, but
>was never adopted.  Am I wrong about that?". Unless Xiaohu has more to
>say, I'm considering the issue closed.
>
>Lou
>---
>
>Lou Berger opened a number of issues
>(https://www.ietf.org/mail-archive/web/idr/current/msg18155.html).
>Discussion of these dominated the WGLC. I tried to follow the discussion
>for each and summarize below. (The below is not a complete set of
>quotations, just headlines.)
>
>After quite a long discussion, Eric agreed
>(https://www.ietf.org/mail-archive/web/idr/current/msg18203.html) to add
>the following, proposed by Lou:
>
>There was a back-and-forth ending with a proposal from Lou
>(https://www.ietf.org/mail-archive/web/idr/current/msg18173.html modified
>by https://www.ietf.org/mail-archive/web/idr/current/msg18177.html,
>modified text shown):
>
>I believe this ended with "Well we disagree."
>(https://www.ietf.org/mail-archive/web/idr/current/msg18195.html). The
>issue is open. (AI: WG)
>
>There was a long exchange on this with Lou taking the position that the
>ability to advertise multiple tunnel types in a single update represents
>unnecessary complexity and Eric taking the position that it's a
>reasonable optimization. Lou and Eric clearly understood each other's
>points but disagreed. Lou provided the caveat that if the mechanism is
>already being used then his objection is withdrawn, however nobody has
>said it's being used so presumably the objection stands.
>
>The authors clearly don't believe a change is warranted, equally clearly
>Lou is unconvinced. The issue is open. (AI: WG)
>
>There was a secondary point raised as part of the exchange
>(https://www.ietf.org/mail-archive/web/idr/current/msg18173.html), I will
>call this 3.a:
>
>This ended with 
>(https://www.ietf.org/mail-archive/web/idr/current/msg18203.html) "Since
>we don't currently know what policies might be needed by a future
>application, we can't specify them now." As far as I can tell this issue
>is closed.
>
>Back-and-forth, agreement to defer. FWIW, I concur that it's fine to
>specify values inline for a new registry (this is not OK for existing
>registries of course), although it's also acceptable to wait and have
>IANA do it if there's no pressing need.
>
>This stands at Lou agreeing it's OK to leave the text as is if desired,
>Eric asked Lou "Was there ever a production deployment? I'm sure the IESG
>will ultimately grill me on this, so I would like to get the facts
>right." I haven't seen a response from Lou on-list. (AI: Lou)
>
>define the format of the Tunnel TLV." (added in
>https://www.ietf.org/mail-archive/web/idr/current/msg18173.html)
>

---

From: John Scudder <[email-masked]>
Date: Fri, 9 Jun 2017 20:08:02 +0000

Thanks, Acee. However, let's plan to do another WGLC when the open items have been addressed. At minimum there is an update needed for the agreed change. 

I don't see any reason a long time has to elapse before we do the repeat WGLC, but this one is now closed. 

--John 

> On Jun 9, 2017, at 3:42 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi John, 
>

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 9 Jun 2017 16:57:56 -0400

> Thanks, Acee. However, let's plan to do another WGLC when the open items have been addressed. At minimum there is an update needed for the agreed change. 

Oh that reminds me, I omitted the "AI: Eric" next to Lou's item 3. Should be obvious, but noted for completeness.

--John

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 13 Jun 2017 13:23:11 -0400

> Back-and-forth, agreement to defer. FWIW, I concur that it's fine to specify values inline for a new registry (this is not OK for existing registries of course), although it's also acceptable to wa…

As it happens, the "Tunnel Encapsulation Attribute Sub-TLVs" registry is 
an existing registry, created by RFC 5512.  The draft does propose to 
change the registration policy by distinguishing several codepoint ranges.

To support the ongoing implementations and deployments, we need a 
codepoint for the following sub-TLV: Remote Endpoint.

To support the ongoing implementations and deployments of 
draft-previdi-idr-segment-routing-te-policy, we need codepoints from the 
same registry for the following sub-TLVs: Preference, Binding SID, and 
Segment List.  These codepoints need to accord with the proposed new 
registration codepoint ranges.

I suppose I could ask for early allocation of "Remote Endpoint", but 
what would really solve the codepoint allocation problem is early 
revision of the registration policy.

I thought about pulling out Section 12.4 (discussing the Tunnel 
Encapsulation Registry Sub-TLVs registry) into a separate draft, but I'm 
not sure the WG would support even that at the current time. Any 
thoughts on that?

The only other feasible option is to form an implementor's agreement, do 
self-allocation, and record the self-allocated values in the draft.  I 
prefer not to do that, but I will if there is no other option that 
enables us to move forward in a timely manner.

>>    than the Encapsulation SAFI.

The following section has been added for the next revision:
----------
1.4.  Impact on RFC 5566

    [RFC5566] uses the mechanisms defined in [RFC5512].  While this
    document obsoletes [RFC5512], it does not address the issue of how to
    use the mechanisms of [RFC5566] without also using the Encapsulation
    SAFI.  Those issues are considered to be outside the scope of this
    document.
----------

> As Job correctly observed, IDR tradition doesn't strictly require implementations in order to complete WGLC, but it's perfectly reasonable for WG participants to predicate their support on implementation.

That's why LC was not requested for this draft (which has  been around 
for a couple of years, I think) until implementations were well underway ;-)

> lack of enthusiasm for reporting implementation status

Sorry, too busy expanding acronyms and double-checking the 
capitalization of the RFC2119 terms ;-)

> nobody has claimed anything other than "partial" support

The whole point is to provide some structure for passing around 
information used to build tunnels.  This eliminates the need for every 
new application to invent ad hoc mechanisms to handle what they take to 
be their immediate tunneling needs.  When someone implements a 
particular application, they would be expected to implement only as much 
of this draft as is needed to support that application.  Someone who 
doesn't, for example, support NVGRE encapsulation, would be unlikely to 
implement the NVGRE encapsulation sub-TLV.  If a need for NVGRE is later 
discovered, it's helpful to have some existing structure with a place to 
hook it in.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 13 Jun 2017 14:57:36 -0400

On Jun 13, 2017, at 1:23 PM, Eric Rosen <[email-masked]> wrote:
> As it happens, the "Tunnel Encapsulation Attribute Sub-TLVs" registry is an existing registry, created by RFC 5512.  The draft does propose to change the registration policy by distinguishing several codepoint ranges.

Thanks for clarifying this; I was relying on the content of the email exchange and hadn't checked the registry existence myself. Sorry for the noise.

> To support the ongoing implementations and deployments, we need a codepoint for the following sub-TLV: Remote Endpoint.
> 
> To support the ongoing implementations and deployments of draft-previdi-idr-segment-routing-te-policy, we need codepoints from the same registry for the following sub-TLVs: Preference, Binding SID, and Segment List.  These codepoints need to accord with the proposed new registration codepoint ranges.  
> 
> I suppose I could ask for early allocation of "Remote Endpoint",  but what would really solve the codepoint allocation problem is early revision of the registration policy. 
> 
> I thought about pulling out Section 12.4 (discussing the Tunnel Encapsulation Registry Sub-TLVs registry) into a separate draft, but I'm not sure the WG would support even that at the current time.  Any thoughts on that?

Of course I can't say whether the WG would support it or not, although it seems to me that given the WG adopted the tunnel-encaps doc as a whole it wouldn't be unreasonable to adopt it piecemeal too. Of course there are points that could be raised pro or con.

It seems to me that given tunnel-encaps is (I hope) near the end of its journey, the time required to extract, adopt, and progress 12.4 independently would probably not be time well spent. It might possibly progress a bit before tunnel-encaps since it would be an administrative document and not be held up by most of the things that could snag tunnel-encaps; then again, as you well know there's overhead in moving even the simplest document. Since I'm still optimistic that tunnel-encaps can be moved relatively soon, my instinct would be to stay the course. I don't insist, though.

> The only other feasible option is to form an implementor's agreement, do self-allocation, and record the self-allocated values in the draft.  I prefer not to do that, but I will if there is no other option that enables us to move forward in a timely manner.

Unsurprisingly, I would like to discourage you from doing that. I would much rather the option of progressing 12.4 as an independent document.

[...]
> That's why LC was not requested for this draft (which has  been around for a couple of years, I think) until implementations were well underway ;-)
> 
> Sorry, too busy expanding acronyms and double-checking the capitalization of the RFC2119 terms ;-)
> 
> The whole point is to provide some structure for passing around information used to build tunnels.  This eliminates the need for every new application to invent ad hoc mechanisms to handle what they take to be their immediate tunneling needs.  When someone implements a particular application, they would be expected to implement only as much of this draft as is needed to support that application.  Someone who doesn't, for example, support NVGRE encapsulation, would be unlikely to implement the NVGRE encapsulation sub-TLV.  If a need for NVGRE is later discovered, it's helpful to have some existing structure with a place to hook it in.

Sure. I guess your point here is that almost any implementation will be "partial". That's fine. I think this means the implementation report will have to have at least a little structure to it, more than currently exists in the wiki. I don't think this needs to be controversial, but it does mean someone has to invest a few hours in structuring the report, and various other people have to invest minutes-to-hours populating it.

Thanks,

--John

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 19 Jun 2017 23:41:23 +0000

I have completed the implementation status using the same Wiki page as
Job. 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implemen
tations

Thanks,
Acee 

On 6/9/17, 4:57 PM, "Idr on behalf of John G. Scudder"
<[email-masked] on behalf of [email-masked]> wrote:

>> Thanks, Acee. However, let's plan to do another WGLC when the open
>>items have been addressed. At minimum there is an update needed for the
>>agreed change. 
>

---

From: <[email-masked]>
Date: Fri, 23 Jun 2017 10:56:15 +0000

Hi Eric,

I wouldn't said that I have reviewed the document (-06), nor the discussion, but section 3.3.1 " IPv4 DS Field" seems IPv4 specific and we probably need to also cover IPv6. Possibly, the same sub-TLV may be used.
In addition, there is the IPv6 flow label, but I don't know whether it would be useful to specify it or not.
 
Thanks,
Regards,
--Bruno

 > A working group last call has been requested for draft-ietf-idr-tunnel-encaps-04. Please
 > reply to the list with your comments. As usual note we cannot advance the draft without
 > participation from the group. Please get your comments in before June 5, 2017.
 > 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 26 Jun 2017 08:47:16 +0000

Hi Eric,

Please find below a possible typo in §2

   Each sub-TLV consists of three fields: a 1-octet type, 1-octet

   length, and zero or more octets of value.  A sub-TLV is structured as

   shown in Figure 2:

                   +-----------------------------------+

                   |      Sub-TLV Type (1 Octet)       |

                   +-----------------------------------+

                   |     Sub-TLV Length (1 or 2 Octets)|

                   +-----------------------------------+

                   |     Sub-TLV Value (Variable)      |

                   |                                   |

                   +-----------------------------------+

               Figure 2: Tunnel Encapsulation Sub-TLV Format

OLD : 1-octet length,

NEW : 1-octet or 2-octets length,

Thanks,

Best regards,

--Bruno

> From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]

> Sent: Friday, June 23, 2017 12:56 PM

> To: [email-masked]

> Cc: [email-masked]

> Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

 > I wouldn't said that I have reviewed the document (-06), nor the discussion, but section

> 3.3.1 " IPv4 DS Field" seems IPv4 specific and we probably need to also cover IPv6. Possibly,

> the same sub-TLV may be used.

> In addition, there is the IPv6 flow label, but I don't know whether it would be useful to

> specify it or not.

>  > [email-masked]<mailto:[email-masked]>

 > _____________________________________________________________________________

> ____________________________________________

 > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou

> privilegiees et ne doivent donc

> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par

> erreur, veuillez le signaler

> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant

> susceptibles d'alteration,

 > This message and its attachments may contain confidential or privileged information that

> may be protected by law;

> If you have received this email in error, please notify the sender and delete this message

> and its attachments.

> As emails may be altered, Orange is not liable for messages that have been modified,

> changed or falsified.

> [email-masked]<mailto:[email-masked]>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 27 Jun 2017 10:55:33 -0400

> In addition, there is the IPv6 flow label, but I don't know whether it would be useful to specify it or not.

It's impossible for a single document to specify a sub-TLV for every 
encapsulation header field that might possibly be useful.  I tried to 
include in the document enough of a selection of sub-TLVs to indicate 
how more might be added.  If someone wants to signal a value for the 
IPv6 flow label field, it should be fairly straightforward to write a 
draft specifying a suitable sub-TLV.

---

From: <[email-masked]>
Date: Tue, 27 Jun 2017 16:21:12 +0000

> From: Eric C Rosen [mailto:[email-masked]]   > Sent: Tuesday, June 27, 2017 4:56 PM
> 

Fair point for the IPv6 flow label.

I don't think the argument work for making the "IPv4 DS Field" IPv4 specific with no provision for IPv6. I see 3 options to cover IPv6:
- one sub-TLV IP version agnostic
- two  2 sub-TLVs IPv4 QoS, IPv6 QoS
- if only one IP version specific sub-TLV can be defined, we may want it to be IPv6 rather than IPv4.

If it's impossible, I guess we can also remove the QoS field. 

--Bruno