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

From: "John G. Scudder" <[email-masked]>
Date: Sat, 20 May 2017 15:47:17 -0400

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

---

From: Job Snijders <[email-masked]>
Date: Sat, 20 May 2017 19:54:36 +0000

Hi,

What implementations of draft-ietf-idr-tunnel-encaps exist as of now?

Kind regards,

Job

On Sat, 20 May 2017 at 21:47, John G. Scudder <[email-masked]> wrote:

> 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.
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "John G. Scudder" <[email-masked]>
Date: Sat, 20 May 2017 16:06:23 -0400

Further to this, it would be helpful if in addition to replying, those reporting implementations created a new document under https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports and listed them there. If you need help with the wiki, let one of the chairs know.

As a reminder, although we don't require implementation in order to WGLC, we do require it in order to progress the document (the implementations MAY be reported after the WGLC that is). Whether WG members choose to consider implementation status in reaching their opinion as to whether the draft is ready to progress is up to them.

--John

> On May 20, 2017, at 3:54 PM, Job Snijders <[email-masked]> wrote:
> 
> Hi,
> 
> On Sat, 20 May 2017 at 21:47, John G. Scudder <[email-masked] <mailto:[email-masked]>> wrote:
> Hi All,
> 
> https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04 <https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04>
> 
> Thanks,
> 
> --John
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Lou Berger <[email-masked]>
Date: Sun, 21 May 2017 15:58:29 -0400

> https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04

Overall I support this document being published, but after addressing
some comments, most importantly the first one:

1. I think this document needs to cover its impact on RF5566.  My
personal preference is for this document to subsume/obsolete 5566, but
the types defined in 5566 shouldn't be lost. (BTW I previously provided
authors with text to allow this draft to obsolete 5566 as well, and can
do so to the list if it would be helpful.)

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

      A Tunnel Encapsulation attribute MUST NOT include a barebones
      Tunnel TLV.  Instead of placing such a TLV in the Tunnel
      Encapsulation attribute attached to a particular route, the
      corresponding Encapsulation Extended Community MUST be attached to
      the route.

Are you saying the extended community MUST be "barebones".  If so, I
agree as this matches 5512 formatting.  If you want this extended
community to carry sub-tlv information, then I see no backwards
compatibility basis for this and don't support this.  Either way, I
think this rule needs to be clarified.

3. I'm not sure why the color sub-tlv is still needed. why not just use
the Color Extended Community alone?  (Is there really a case where the
recursive lookup in section 7 would have a different color?)

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

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 as it can be found implemented in FRRouting (a fork of
quagga). This said, I fully support its depreciation and look forward to
submitting the patch that will remove it!  Just drop the two never used
comments.

- Since the question was raised on list: a partial implementation of
this draft can be found in FRRouting, notably bgp_encap_tlv.{h,c} in
https://github.com/FRRouting/frr/tree/master/bgpd . It supports:

 o encap attribute sent with other safis.  The code uses it with the
   VPN safi to provide underlay tunnel information for VPN routes for
   NVO3 type applications.

 o "Remote Endpoint Address sub-TLV" for v4 and v6

 o encode/decode of type specific and sub-TLV formats
   per draft -00 or -01 rev (this means it is a subset implementation.

This is open source code so anyone is free to review and submit changes.

Lou

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 22 May 2017 09:19:56 -0400

I am not aware of any undisclosed relevant IPR.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 22 May 2017 10:51:05 -0400

> do so to the list if it would be helpful.)

It is true that this document orphans RFC 5566 by obsoleting a document 
on which 5566 has a normative dependency.  However, incorporating the 
security-related material from 5566 in a way that makes it useful is 
going to be a fair amount of work, and the rest of the document 
shouldn;'t be held up waiting for that.  If you have some simple and 
non-controversial text to suggest, let's consider it.  (I checked my old 
emails on this topic but couldn't find it.)

> think this rule needs to be clarified.

I'm not sure I understand what you are objecting to.  An extended 
community cannot carry sub-TLVs.

A number of existing applications exist that use the Encapsulation EC to 
specify a tunnel type, with no parameters.  The above-quoted paragraph 
attempts to encourage backwards compatibility with those applications by 
saying that if you want to specify a single tunnel type with no 
parameters, use the Encapsulation EC.  The Tunnel Encaps attribute would 
be used whenever the Encapsulation EC  is not sufficient.

> recursive lookup in section 7 would have a different color?)

The color sub-TLV is per-tunnel, the color EC is per route.  You could 
have multiple tunnels to a given endpoint, each with a different color.

> newly established Tunnel Encapsulation Attribute Sub-TLVs registry.

I am under the impression that the preferred procedure is for the values 
to be assigned by IANA, not by the drafts.

> submitting the patch that will remove it!  Just drop the two never used

Since you are looking forward to removing the Encapsulation SAFI, I 
guess it is safe to say that there is no production deployment of it.  
If that's the case, I think "never used" is accurate.

---

From: Keyur Patel <[email-masked]>
Date: Mon, 22 May 2017 16:32:37 +0000

Regards,
Keyur

On 5/22/17, 6:19 AM, "Idr on behalf of Eric C Rosen" <[email-masked] on behalf of [email-masked]> wrote:

---

From: [email-masked]
Date: Mon, 22 May 2017 16:34:11 +0000 (UTC)

I am not aware of any IPR 

G/

Get Outlook for Android

On Mon, May 22, 2017 at 6:32 PM +0200, "Keyur Patel" <[email-masked]> wrote:

Regards,
Keyur

On 5/22/17, 6:19 AM, "Idr on behalf of Eric C Rosen"  wrote:

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 May 2017 08:45:07 -0400

On 5/22/2017 10:51 AM, Eric C Rosen wrote:
> shouldn;'t be held up waiting for that.  
Well I did make this comment ~ 2 years ago, so you shouldn't be
surprised that I'm raising it now.  I'm not saying the WG has to follow
my preferred path (of having this doc replace 5566 as well), but I think
something has to be done to not leave 5566 "orphaned".

> If you have some simple and 
my memory is that I put together a rough google doc at the time we
discussed whether your doc would deprecate 5512 or not.  (See
https://docs.google.com/document/d/1PSVTwf_QaRVWqhmkfaoRuP2JoGq_Nq9mlICUv6Z2BOQ/edit)

To have tunnel-encaps deprecate 5566 as well, I think the following is
needed:
- Include the 5566 defined tunnel types (particularly 4, 5 and 6)
- include section 3.4.1 and 3.6 from the google doc (which is just edit
text from 5566 sections 3 and 4)
- perhaps include the 2nd paragraph of the Security Considerations section

Given that the text is mostly lifted from 5566, I'd hope this qualifies
as "simple and non-controversial".

(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.  Don't you think it should?
Obviously, I do. Feel free to lift Section 3 of the google doc.

> community cannot carry sub-TLVs.

Perfect.  That's what I was hoping for/expecting, but I couldn't parse
your text in a way that made sense (at least to me). I also think the
current phasing goes beyond what some implementations do, e.g., send a
barebones EC all the time.

> be used whenever the Encapsulation EC  is not sufficient.
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 endpoint. The corresponding
barebones
   Tunnel Encapsulation attribute MAY be omitted in this case.

BTW our implementation always includes a "barebones" Encapsulation
Extended Community ;-)

> have multiple tunnels to a given endpoint, each with a different color.
okay, this works -- we solved this using multiple updates.   That said,
do you think the complexity of multiple tunnel tlvs in the same update
is needed or really used today (vs just using multiple/per tunnel tlv
updates)?  The encap safi certainly resulted in some pretty complex code
in order to "optimize" update sizes.  It seems that this too is a
similar trade off, and would be a good additional area of complexity
that can be simplified.  If it's not used today, I think we should
restrict the Tunnel Encapsulation Attribute to one Tunnel-TLV.

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

> to be assigned by IANA, not by the drafts.

I don't think this is the case for *new* registries.  We can defer to
the Doc shepherd on this and not discuss further.

> If that's the case, I think "never used" is accurate.

"never used" is not the same as "not currently used".  The latter is
accurate, the former is not.  I can live with this (pedantic)  inaccuracy.

Lou

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 23 May 2017 11:04:33 -0400

> as "simple and non-controversial".

RFC 5566 assumes that the IPsec tunnel info and the authenticator 
sub-TLV is conveyed on an update of the encapsulation SAFI.   I'm not 
convinced that there are no addtional security issues to be considered 
if this information is carried on updates of other address families.  
Also, note that in RFC 5512, the tunnels only extend to the BGP next 
hop, while in the tunnel-encaps draft the tunnel endpoints are not 
necessarily the BGP next hop.  This might also change some of the 
security properties.  I think this would have to be thought out fairly 
thoroughly, and I don't think that work's been done yet.

Given that no one's been motivated to do the necessary work over the 
past two years, I don't think the draft should be held up waiting for it.

> Obviously, I do. Feel free to lift Section 3 of the google doc.

Figure 1 is not satisfactory?

> BTW our implementation always includes a "barebones" Encapsulation

For anyone trying to follow this thread, the Encapsulation EC was 
defined in RFC5512 as a simple way to specify a tunnel whose endpoint is 
the BGP next hop, and for which no encapsulation information needs to be 
provided.  That is, only the tunnel type is identified, and nothing is 
said about how to form the encapsulation for that tunnel, how to choose 
which packets go through that tunnel, etc.  In the draft, a "barebones 
Tunnel TLV" is defined to be a Tunnel TLV that that only specifies the 
tunnel type, and hence could just as well be encoded in the 
Encapsulation EC.

I don't see how it could be correct for an implementation to always 
include an Encapsulation EC.  Sometimes you need to specify more than 
the tunnel type in order to construct the encapsulation properly.

I don't think your suggested text is accurate, because a barebones 
Tunnel TLV does not identify a tunnel endpoint.

> restrict the Tunnel Encapsulation Attribute to one Tunnel-TLV.

The use of multiple tunnels between a pair of endpoints seems to make 
sense, especially if the tunnels have different characteristics, and if 
color can be used to map particular traffic flows to particular 
tunnels.    This is something that has not changed from RFC 5512.  Note 
also that even the Encapsulation EC allows multiple tunnels to be 
specifiied (if they are of different types), since an EC attribute can 
contain multiple instances of the same extended community.

> If this is kept, it seems like there's some special aggregation rules

I'm not sure I understand this point.  If you receive two routes, and 
want to aggregate them so that you onluy need to propagate one upstream, 
and the two routes have different tunnel-encaps attributes, you need 
some policy to decide what to do.  But that's true even if the 
tunnel-encaps attribute only specifies one tunnel.

> the Doc shepherd on this and not discuss further.

I'm sure that whichever way I do it, the document shepherd will tell me 
it's the wrong way ;-)

> accurate, the former is not.  I can live with this (pedantic)  inaccuracy.

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.

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 May 2017 12:10:46 -0400

> if this information is carried on updates of other address families. 

I think the assumption is that the sub-TLVs are conveyed with the
attribute.  I don't see how changing the SAFI impacts this.

> thoroughly, and I don't think that work's been done yet.

So leaving 5566 as is introduces this issue already (due to the
introduction of the remote endpoint sub-tlv).  If the we deprecate 5566
with this document, this can be trivially addressed by saying that the
endpoint Authenticator sub-tlv applies to the endpoint identified in the
Remote Endpoint Sub-TLV.
> past two years, I don't think the draft should be held up waiting for it.
Well the document was dormant for a time and had I realized it was
coming up for LC I would have offered to do the work yet again.  I guess
that's part of the reason to do a LC.

> Figure 1 is not satisfactory?

Yes it is - I should have had another cup of coffee before sending the
message!

> the tunnel type in order to construct the encapsulation properly.

It doesn't "hurt" to include it always and there is an implementation
that does this, so why not allow it?

> Tunnel TLV does not identify a tunnel endpoint.

then just s/endpoint/type

> contain multiple instances of the same extended community.

I'm not arguing it that it's not a real use case, but rather that it can
be solved using other existing, albeit more verbose, mechanisms.  Just
like encap safi itself, if no one is using this, I think it would be
better to simplify the solution and associated code.  If you are already
making use of this in deployed code, then I withdraw the proposed
simplification.

> tunnel-encaps attribute only specifies one tunnel.
Sure, and the policy may be to merge the tlv lists.  This is the kind of
information I'm suggesting should be added.

>...

Lou

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 24 May 2017 12:32:07 +0000

Hi all,

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

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Idr [mailto:[email-masked]] 代表 John G. Scudder
> 发送时间: 2017年5月21日 3:47
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: [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.
>

---

From: Job Snijders <[email-masked]>
Date: Thu, 25 May 2017 15:54:24 +0200

Dear all,

TL;DR: I do not support advancing this document at this time. Lack of
full-spec implementation experience, and little feedback from actual
implementers, lead me to not support progression of this document. I
understand that this position has little to do with the actual contents
of the document.

On Sun, May 21, 2017 at 03:58:29PM -0400, Lou Berger wrote:
> > comments. As usual note we cannot advance the draft without
> > participation from the group. Please get your comments in before
> > June 5, 2017.
> 

Cool stuff, thanks for sharing that!

While John Scudder pointed out that there is no blocking requirement for
a document to have implementations before passing through WG LC. I (and
probably participants too) am of the opinion that actual feedback from
implementers is extremely valuable.

Should an implementer find an actual technology issue, or lack of
clarity in the wording of the document, as long as the document in the
WG it'll be trivial to resolve any issues. I understand that there are
ways to modify a document after WG LC, but I think its simpler to be
able to say to the working group itself "this technology works, i have
an implementation".

Should someone write a partial implementation, that might be a hint that
the document needs to be split up (or perhaps it is of no significance).
To properly assess a document, I hope for feedback from full
implementations (perhaps two technology components within a doc conflict
with each other). If parts of an Internet-Draft are not implemented by
anyone, I'd advocate the document should not (yet) progress further.

With "implementation" i don't mean that you are shipping code to
customers, I'm fine with stuff hanging in private beta branches - all
I'm looking for is an attestation that the implementer found the
full specification implementable. RFC7942 is good guidance.

I'd like to request the chairs to consider a slight adjustment of the
procedure: encourage the working group to create implementations
_before_ WGLC, so the working group can take implementer feedback into
account when assessing the proposed document.

Kind regards,

Job

ps. if two full implementations show up during this WGLC, I will
ofcourse withdraw my non-support.

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 25 May 2017 13:54:02 -0400

> attribute.  I don't see how changing the SAFI impacts this.

I'm not saying that it does or does not, just that I'm not sure, and I'm 
not prepared now to defend a claim that the security aspects are not 
altered by this change.  So I'd rather see that addressed in a different 
document.

> endpoint Authenticator sub-tlv applies to the endpoint identified in the

I'm also not prepared to defend a claim that this is has no signficant 
impact to the security characteristics.

Since the existing contents of the document do not depend upon anything 
in RFC 5566, I think obsoleting and replacing RFC 5566 is better done in 
a separate document .

> that does this, so why not allow it?

It seems to me that it does hurt to include it.  If the intended tunnel 
endpoint is not the BGP next hop, or if the tunnel will not work unless 
the encapulation is prepared as specified within the attribute, then 
including an encapsulation EC for the same tunnel type provides false 
information.

>> be solved using other existing, albeit more verbose, mechanisms.

Allowing a choice of tunnels between a pair of endpoints should not 
require the origination of multiple routes with different NLRIs, or 
(even worse) the use of add-paths.  I don't really see the merit of this 
suggestion.

>> If you receive two routes, and
>> want to aggregate them so that you only need to propagate one upstream,

I think such policies will be very application-specific, and thus are 
out of scope of this document.  A draft proposing the use of the tunnel 
encaps attribute for a particular purpose might well have to deal with 
these policy issues.

---

From: John E Drake <[email-masked]>
Date: Thu, 25 May 2017 18:10:11 +0000

Hi,

Is it really the responsibility of  a RFC which obsoletes a another RFC to explain how every RFC referencing the obsoleted RFC is to be updated?  I think it's a much better idea to  update each of these RFCs individually.  So, as Eric suggests, I think an update to RFC 5566 is in order.

Yours Irrespectively,

John

From: Idr [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Thursday, May 25, 2017 1:54 PM
To: Lou Berger <[email-masked]>; John Scudder <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

I'm not saying that it does or does not, just that I'm not sure, and I'm not prepared now to defend a claim that the security aspects are not altered by this change.  So I'd rather see that addressed in a different document.

Remote Endpoint Sub-TLV.

I'm also not prepared to defend a claim that this is has no signficant impact to the security characteristics.

Since the existing contents of the document do not depend upon anything in RFC 5566, I think obsoleting and replacing RFC 5566 is better done in a separate document .

It seems to me that it does hurt to include it.  If the intended tunnel endpoint is not the BGP next hop, or if the tunnel will not work unless the encapulation is prepared as specified within the attribute, then including an encapsulation EC for the same tunnel type provides false information.

Allowing a choice of tunnels between a pair of endpoints should not require the origination of multiple routes with different NLRIs, or (even worse) the use of add-paths.  I don't really see the merit of this suggestion.

I think such policies will be very application-specific, and thus are out of scope of this document.  A draft proposing the use of the tunnel encaps attribute for a particular purpose might well have to deal with these policy issues.

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 May 2017 16:33:07 -0400

On 5/25/2017 1:54 PM, Eric C Rosen wrote:
> I'm not saying that it does or does not, just that I'm not sure, and
> I'm not prepared now to defend a claim that the security aspects are
> not altered by this change.  So I'd rather see that addressed in a
> different document.
Well both of these are different statements than you made before.

So the way you'd prefer to resolve the 5566 issue is to leave it for the
future.  I can live with that, but think this should be made explicit
since 5512 is being deprecated.  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. 

> Since the existing contents of the document do not depend upon
> anything in RFC 5566, I think obsoleting and replacing RFC 5566 is
> better done in a separate document .
>

That's fine assuming something like the above.

> It seems to me that it does hurt to include it.  If the intended
> tunnel endpoint is not the BGP next hop, or if the tunnel will not
> work unless the encapulation is prepared as specified within the
> attribute, then including an encapsulation EC for the same tunnel type
> provides false information.

Well we disagree.

Going back to your original text, if I read it right, sole use of the EC
was required in the case of a barebones "attribute".  Is this correct? 

If so, I certainly don't think it's reasonable to require use of EC in
some cases and attribute in others.  Allowing for both certainly has
maximal interop, but I think the required baseline should be the common
one, ie., tunnel attribute, not the special case; and EC can be added in
the barebones case.

> (even worse) the use of add-paths.  I don't really see the merit of
> this suggestion.
The point is simplification for an unused use case.  Is your position
based on theory or actual use?  As I mentioned before, if the latter I
withdraw this proposed simplification.  If the former, I think we should
simplify this case, just like we're eliminating Encap SAFI even though
it provides good theoretical benefits in advertisements.

> out of scope of this document.  A draft proposing the use of the
> tunnel encaps attribute for a particular purpose might well have to
> deal with these policy issues.
>

Sounds like a future interop issue to me.  

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 May 2017 17:04:23 -0400

considering the impact of deprecating an RFC on other RFCs seems to me
to be a reasonable thing to cover in the rfc doing the deprecating...

On 5/25/2017 2:10 PM, John E Drake wrote:
>
> Hi,
>
>  
>
> Is it really the responsibility of  a RFC which obsoletes a another
> RFC to explain how every RFC referencing the obsoleted RFC is to be
> updated?  I think it’s a much better idea to  update each of these
> RFCs individually.  So, as Eric suggests, I think an update to RFC
> 5566 is in order.
>
>  
>
> Yours Irrespectively,
>
>  
>
> John
>
>  
>
> *From:*Idr [mailto:[email-masked]] *On Behalf Of *Eric C Rosen
> *Sent:* Thursday, May 25, 2017 1:54 PM
> *To:* Lou Berger <[email-masked]>; John Scudder <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Idr] Working group last call for
> draft-ietf-idr-tunnel-encaps-04
>
>  
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 May 2017 11:39:48 +0900

> to be a reasonable thing to cover in the rfc doing the deprecating...

the transitive closure, while bounded, could be quite large

>> RFCs individually.  So, as Eric suggests, I think an update to RFC

this makes more sense

randy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 26 May 2017 15:26:17 +0000

Hi Job, 
Cisco is supporting Tunnel Attribute parsing and propagation as well as
the TE-Policy tunnel type in an unreleased version of IOS-XR. The SR-TE
Policy draft is 
https://www.ietf.org/id/draft-previdi-idr-segment-routing-te-policy-05.txt.
Thanks,
Acee 

On 5/25/17, 9:54 AM, "Idr on behalf of Job Snijders" <[email-masked]

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 26 May 2017 11:42:56 -0400

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.

---

From: Job Snijders <[email-masked]>
Date: Fri, 26 May 2017 17:45:29 +0200

Hi Acee,

On Fri, May 26, 2017 at 03:26:17PM +0000, Acee Lindem (acee) wrote:
> Cisco is supporting Tunnel Attribute parsing and propagation as well
> as the TE-Policy tunnel type in an unreleased version of IOS-XR. The
> SR-TE Policy draft is 

Since nobody took up John's suggestion to create a wiki page, I've
created this empty page here
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations
and linked it from the main overview
https://trac.ietf.org/trac/idr/wiki/Protocol%20implementations%20Reports

Can perhaps you or a colleague, and other implementers please fill in
the details? :) 

Kind regards,

Job

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 26 May 2017 15:48:41 +0000

Hi Job, 

>Can perhaps you or a colleague, and other implementers please fill in

Sure - we will update.

Thanks,
Acee

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 26 May 2017 12:31:29 -0400

On 5/25/2017 4:33 PM, Lou Berger wrote:
> 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

I'll be happy to add this text.

>> based on theory or actual use?

As it happens, I was just yesterday asked by an implementer whether a 
receiving endpoint could advertise two tunnels and allow the 
transmitting endpoint to select one, so there does seem to be an 
immediate use case.

However, I regard it as very obvious that you might want to advertise 
several tunnels, along with some criteria for selecting which traffic 
goes into which tunnel.   There are numerous cases where this is done by 
configuring the transmitting and receiving endpoints of the tunnel, so I 
don't see why someone would regard the ability to signal this 
information as "theoretical".

>> Sounds like a future interop issue to me.

Since we don't currently know what policies might be needed by a future 
application, we can't specify them now.  Of course, whenever it is 
necessary to provision policies, there are potential interop issues if 
different implementation cannot support a common set of policies.

---

From: Lou Berger <[email-masked]>
Date: Fri, 26 May 2017 19:14:58 -0400

> information as "theoretical".

Humm it also seems obvious to define a way to advertise changes in number 
of tunnels and tunnel attributes without also having to re advertising all 
the prefixes reachable over the tunnels - let's do that too as it obviously 
dramatically reduces update processing.  Think of it no need to advertise 
those thousands of prefixes just because some tunnels were added/removed, 
right?

But wait - we did that and have now decided that the complexity of the 
processing isn't worth optimizing such advertisment as *in practice* it is 
a corner use case. So, while I agree that supporting multiple tunnels for 
the same prefix is a real use case, I still question if having a second 
"optimized" mechanism to signal the tunnel information (in multiple 
sub-TLVs in the same attribute) is worth the implementation overhead. Note 
that the " suboptimal" mechanism will still have to be supported anyway 
since it just falls out of the definition, and also supports different 
lifetimes in tunnel endpoint management.

Lou
...

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 29 May 2017 15:16:20 -0400

> 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.ie…

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?

---

From: John E Drake <[email-masked]>
Date: Tue, 30 May 2017 19:44:51 +0000

John,

I support advancing this draft as it extremely solid and comprehensive and it has already proven to be extensible to solve a number of problems, e.g., SR traffic engineering, SR DCI, and SFC, for which it was not originally designed.

Yours Irrespectively,

John

> -----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,
>