Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

Gyan,

The authors can confirm, but my reading of draft-ietf-idr-tunnel-encaps is that it is perfectly backwards compatible with the encapsulation extended community used in RFC8365.
So RFC8365 implementations don’t need to change at all. That’s my reading of the encapsulation extended community section.

Only in case of requiring the tunnel encapsulation attribute for any other reason, then an implementor should look at the rules included in this draft.

My two cents.

Thanks.
Jorge

From: Idr <idr-bounces@ietf.org> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
Date: Friday, May 8, 2020 at 9:48 AM
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, Keyur Patel <keyur@arrcus.com>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

Hi Keyur and other others of this draft.

For vxlan evpn NVO3 RFC 8365 describes the vxlan BGP EVPN overlay architecture and the various encapsulation types below that exist today and have been implemented now by most vendors.

https://tools.ietf.org/html/rfc8365

Value    Name

   -----    ------------------------

   8        VXLAN Encapsulation

   9        NVGRE Encapsulation

   10       MPLS Encapsulation

   11       MPLS in GRE Encapsulation

   12       VXLAN GPE Encapsulation

So RFC 8365  has been implemented and it works without this drafts tunnel encapsulation attribute new SAFI defined.

So would this draft once it gets WG adoption update RFC 8365 and any other encapsulation types that work today without this encapsulation attribute.  Would that require vendor to update their code to now support this SAFI.

Since RFC 8365 NVO3 vxlan evpn works well today without this tunnel attributes, please specify what is gained by having vendors update their code to support this new tunnel attribute.

Please help shed some light on this topic.

Kind regards

Gyan
Verizon

On Thu, May 7, 2020 at 2:51 PM John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Hi Alvaro,

On Feb 21, 2020, at 7:47 AM, Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>> wrote:

[minor] "topmost" and "bottommost" are not mentioned in rfc3032.
Please be consistent with the terminology.  It is ok to introduce new
terminology, if needed, but please explain that as well.

RFC 3032 is careful in defining what “top” and “bottom” mean for labels of course. Don’t you think the meanings of “topmost” and “bottommost” are obvious in that context?

—John
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>