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

Thanks Jorge.  John confirmed that it does not update RFC 8365 or any of
the other encapsulation RFCs.

Thanks

Gyan

On Fri, May 8, 2020 at 4:14 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.rabadan@nokia.com> wrote:

> 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> wrote:
>
> Hi Alvaro,
>
>
>
> On Feb 21, 2020, at 7:47 AM, Alvaro Retana <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
> 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
>
>
>
>
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com