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

From: John Scudder <[email-masked]>
Date: Fri, 1 May 2020 21:06:56 +0000

Hi Alvaro,

On Feb 21, 2020, at 7:47 AM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

[major] rfc5512 said that "Unknown types are to be ignored and skipped
upon receipt."  Is that still the case?

Yes. As I read it, this is covered in greater detail by section 11:

   If a Tunnel Encapsulation attribute can be parsed correctly, but
   contains a TLV whose tunnel type is not recognized by a particular
   BGP speaker, that BGP speaker MUST NOT consider the attribute to be
   malformed.  Rather, the TLV with the unrecognized tunnel type MUST be
   ignored, and the BGP speaker MUST interpret the attribute as if that
   TLV had not been present.

—John

---

From: John Scudder <[email-masked]>
Date: Fri, 1 May 2020 21:11:24 +0000

Whoops, this

> [major] Does this text from rfc5512 apply?
> 
>    When the TLV is being processed by a BGP speaker that will be
>    performing encapsulation, any unknown sub-TLVs MUST be ignored and
>    skipped.  However, if the TLV is understood, the entire TLV MUST
>    NOT be ignored just because it contains an unknown sub-TLV.

is covered by section 11 as well:

   If a TLV of a Tunnel Encapsulation attribute contains a sub-TLV that
   is not recognized by a particular BGP speaker, the BGP speaker MUST
   process that TLV as if the unrecognized sub-TLV had not been present.

Section 11 goes into a lot more detail on sub-TLV handling besides.

—John

---

From: John Scudder <[email-masked]>
Date: Mon, 4 May 2020 19:57:08 +0000

Hi Alvaro,

428    o  The IP address in the sub-TLV's address subfield is not a valid IP
429       address (e.g., it's an IPv4 broadcast address).

[major] What is a "valid IP address"?  The text above says that
link-local are not allowed...and that a host address is expected...and
that the address must "belong"...now you added broadcast addresses.
Anything else?  Is a multicast destination "valid"?  Is there a
reference that can be added here to avoid having to define it?

This problem has been around from time immemorial; for example RFC 4271 has a couple of places where it says things like

   Syntactic correctness means that the NEXT_HOP attribute represents a
   valid IP host address.

I remember wrestling with this in years past, but I’m not sure I ever came up with a good solution. The best reference I can find is RFC 6890, "Special-Purpose IP Address Registries”, which defines what we generally refer to as “martians”. Using that, perhaps the rule could be rewritten something like this?

"o The IP address in the sub-TLV’s address subfield is listed in the relevant Special-Purpose IP Address Registry [RFC6890] as either not a valid destination, or not forwardable.”

In practice this would probably be implemented by using the implementation-specific “martian” list, but this gives us a way to cite it normatively. By the way, this nominally makes the text about link-local redundant, since both the v4 and v6 special-purpose registries include link-local.

—John

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 4 May 2020 13:22:00 -0700

John:

Hi!

I think that pointing at rfc4271 may be better; it explicitly talks about
the address being a host route, and it is akin to the NEXT-HOP…

Thanks!!

Alvaro.

On May 4, 2020 at 3:57:10 PM, John Scudder ([email-masked]) wrote:

Hi Alvaro,

On Feb 21, 2020, at 7:47 AM, Alvaro Retana <[email-masked]> wrote:

This problem has been around from time immemorial; for example RFC 4271 has
a couple of places where it says things like

I remember wrestling with this in years past, but I’m not sure I ever came
up with a good solution. The best reference I can find is RFC 6890,
"Special-Purpose IP Address Registries”, which defines what we generally
refer to as “martians”. Using that, perhaps the rule could be rewritten
something like this?

"o The IP address in the sub-TLV’s address subfield is listed in the
relevant Special-Purpose IP Address Registry [RFC6890] as either not a
valid destination, or not forwardable.”

In practice this would probably be implemented by using the
implementation-specific “martian” list, but this gives us a way to cite it
normatively. By the way, this nominally makes the text about link-local
redundant, since both the v4 and v6 special-purpose registries include
link-local.

—John

---

From: John Scudder <[email-masked]>
Date: Mon, 4 May 2020 20:24:41 +0000

Seriously? Doesn’t this just turn into a question of “but what do you mean by ‘valid IP host address’” then? By contrast, referencing RFC 6890 (and associated registries, by the transitive property or something) means that there’s a specific definition the implementor can dig their teeth into.

Thanks,

—John

On May 4, 2020, at 4:22 PM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

John:

Hi!

I think that pointing at rfc4271 may be better; it explicitly talks about the address being a host route, and it is akin to the NEXT-HOP…

Thanks!!

Alvaro.

On May 4, 2020 at 3:57:10 PM, John Scudder ([email-masked]<mailto:[email-masked]>) wrote:

Hi Alvaro,

—John

---

From: John Scudder <[email-masked]>
Date: Mon, 4 May 2020 20:29:27 +0000

Hi Alvaro,

431    o  It can be determined that the IP address in the sub-TLV's address
432       subfield does not belong to the non-zero AS whose number is in the
433       its Autonomous System subfield.  (See section Section 13 for
434       discussion of one way to determine this.)

[major] "one way"  I hope that it is the MTI way -- otherwise, the
determination of the sub-TLV being malformed is not deterministic.

ISTM (I am just guessing though) that the “it can be determined” language was finely crafted to avoid this exact objection. It makes the entire clause optional.

If we try to make determination of IP address belonging to a given AS mandatory, I think we are opening a can of worms, since although RPKI deployment has made a lot of progress, it’s far from universal. I think we are better off leaving this as written, IMO.

—John

---

From: John Scudder <[email-masked]>
Date: Mon, 4 May 2020 20:50:32 +0000

Hi Alvaro,

442    When redistributing a route that is carrying a Tunnel Encapsulation
443    attribute containing a TLV that itself contains a malformed Tunnel
444    Endpoint sub-TLV, the TLV MUST be removed from the attribute before
445    redistribution.

[minor] This paragraph seems to say the same thing as §11, but please
take it out and specify things only once.

You’re referring to this paragraph in section 11?

   In general, if a TLV contains a sub-TLV that is malformed (e.g.,
   contains a length field whose value is not legal for that sub-TLV),
   the sub-TLV should be treated as if it were an unrecognized sub-TLV.
   This document specifies one exception to this rule -- within a tunnel
   encapsulation attribute that is carried by a BGP UPDATE whose AFI/
   SAFI is one of those explicitly listed in the second paragraph of
   Section 5, if a TLV contains a malformed Tunnel Egress Endpoint sub-
   TLV (as defined in Section 3.1), the entire TLV MUST be ignored, and
   MUST be removed from the Tunnel Encapsulation attribute before the
   route carrying that attribute is redistributed.

I’m inclined to agree with you that it covers the same ground. There is one difference, though: the section 11 paragraph is conditioned on the second paragraph of section 5:

   The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
   UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
   Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
   1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
   or 25/70 (Ethernet VPN, usually known as EVPN)).  Use of the Tunnel
   Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
   outside the scope of this document.

So the section 3.1 language you quoted could be considered to mean something just slightly different. Options I can think of include:

- Ditch the section 3.1 language anyway, it’s close enough and besides section 5 says that all other AFI/SAFI are “beyond the scope of this document”.
- Leave the section 3.1 language, because it’s more general.
- Get rid of the condition in the section 11 language. (And also get rid of the 3.1 language.)

I kind of like the third option. Thoughts? (Not just from Alvaro but from the authors and the WG?)

—John

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 5 May 2020 10:20:25 -0400

<wg-member hat on> 

I like option 3. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Monday, May 4, 2020 4:51 PM
To: Alvaro Retana
Cc: [email-masked]; [email-masked]; idr@ietf. org
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

Hi Alvaro,

442

   When redistributing a route that is carrying a Tunnel Encapsulation
443

   attribute containing a TLV that itself contains a malformed Tunnel
444

   Endpoint sub-TLV, the TLV MUST be removed from the attribute before
445

   redistribution.

—John

---

From: John Scudder <[email-masked]>
Date: Thu, 7 May 2020 18:51:20 +0000

Hi Alvaro,

[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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 03:47:49 -0400

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=
[email-masked]> wrote:

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

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 8 May 2020 08:14:08 +0000

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 <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Friday, May 8, 2020 at 9:48 AM
To: John Scudder <jgs=[email-masked]>, Keyur Patel <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "idr@ietf. org" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

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.

Value    Name

   8        VXLAN Encapsulation

   9        NVGRE Encapsulation

   10       MPLS 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.

Kind regards

Gyan
Verizon

On Thu, May 7, 2020 at 2:51 PM John Scudder <jgs=[email-masked]<mailto:[email-masked]>> wrote:
Hi Alvaro,

—John
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr
--
Gyan  Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>

---

From: John Scudder <[email-masked]>
Date: Fri, 8 May 2020 12:09:46 +0000

Gyan,

One process-ish answer as co-chair and document shepherd:

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

WG adoption is complete, as is WGLC. The email you’re seeing now are replies as we (authors and shepherd) work through Alvaro’s very detailed AD review, preparatory to the IESG taking it up for advancement to RFC. 

The spec doesn’t update 8365 and so on, so I think the simple answer to your questions is “no”. 

—John

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 10:18:00 -0400

Great

Thanks You

Gyan

On Fri, May 8, 2020 at 8:10 AM John Scudder <[email-masked]> wrote:

> > 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.
>
> WG adoption is complete, as is WGLC. The email you’re seeing now are
> replies as we (authors and shepherd) work through Alvaro’s very detailed AD
> review, preparatory to the IESG taking it up for advancement to RFC.
>

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 10:20:12 -0400

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) <
[email-masked]> 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 <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Friday, May 8, 2020 at 9:48 AM
> *To: *John Scudder <jgs=[email-masked]>, Keyur Patel <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "idr@ietf. org" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15
>
>
>
>
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: John E Drake <[email-masked]>
Date: Fri, 8 May 2020 15:20:06 +0000

Gyan,

RFC 8365 uses the Encapsulation extended community rather than the attribute, and the extended community was included in the subject draft.  Please see:  https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-15#section-4.1.

Yours Irrespectively,

John

Juniper Business Use Only
From: Idr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Friday, May 8, 2020 3:48 AM
To: John Scudder <jgs=[email-masked]>; Keyur Patel <[email-masked]>
Cc: [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

https://tools.ietf.org/html/rfc8365<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8365__;!!NEt6yMaO-gk!UooxTZahHMICVYaZqcK72zbOvJNgXz33ZkC1mYjMqeTLuX7IcixCgnvBeqHrO0Q$>

Value    Name

   8        VXLAN Encapsulation

   9        NVGRE Encapsulation

   10       MPLS Encapsulation

Kind regards

Gyan
Verizon

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
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!UooxTZahHMICVYaZqcK72zbOvJNgXz33ZkC1mYjMqeTLuX7IcixCgnvBWS-wehs$>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 8 May 2020 12:34:44 -0400

That section speaks clearly to the backwards compatibility to use the
existing encapsulation extended community instead of the new SAFI tunnel
attribute.

Perfect.

Gyan

On Fri, May 8, 2020 at 11:20 AM John E Drake <[email-masked]> wrote:

> Gyan,
>
>
>
> RFC 8365 uses the Encapsulation extended community rather than the
> attribute, and the extended community was included in the subject draft.
> Please see:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-15#section-4.1
> .
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Friday, May 8, 2020 3:48 AM
> *To:* John Scudder <jgs=[email-masked]>; Keyur Patel <
> [email-masked]>
> *Cc:* [email-masked]; idr@ietf. org <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8365__;!!NEt6yMaO-gk!UooxTZahHMICVYaZqcK72zbOvJNgXz33ZkC1mYjMqeTLuX7IcixCgnvBeqHrO0Q$>
>
>
>
> Value    Name
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!UooxTZahHMICVYaZqcK72zbOvJNgXz33ZkC1mYjMqeTLuX7IcixCgnvBWS-wehs$>
>
> --
>
> Gyan  Mishra
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 May 2020 08:21:59 -0700

On May 4, 2020 at 4:24:45 PM, John Scudder ([email-masked]) wrote:

Seriously? Doesn’t this just turn into a question of “but what do you mean
by ‘valid IP host address’” then? By contrast, referencing RFC 6890 (and
associated registries, by the transitive property or something) means that
there’s a specific definition the implementor can dig their teeth into.

This is what I’m thinking:  the IP address we’re talking about is akin to
the NEXT_HOP.  As you pointed out, the same clarity issues (for the
NEXT_HOP) exist in rfc4271.

Pointing to rfc6890 may be a good solution, but doing so in this draft and
not in rfc4271 seems inconsistent to me.  If rfc6890 is the solution to the
validity question, then we should have rfc4271 use it — IOW, what ever
rfc4271 uses should also be used by this document.

But without having an answer (yet) for rfc4271, then I think the best we
can do with this document is to point to it.  We can then “fix” rfc4271,
which would automagically fix this document as well.  I’m sure we’re not
ready for a bis, but a small document updating would be enough.

My 2c.

Alvaro.

Thanks,

—John

On May 4, 2020, at 4:22 PM, Alvaro Retana <[email-masked]> wrote:

John:

Hi!

Thanks!!

Alvaro.

Hi Alvaro,

—John

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 May 2020 08:29:08 -0700

On May 4, 2020 at 4:29:30 PM, John Scudder wrote:

John:

Hi!

> > On Feb 21, 2020, at 7:47 AM, Alvaro Retana wrote:
> ISTM (I am just guessing though) that the “it can be determined” language
> was finely crafted to avoid this exact objection. It makes the entire
> clause optional.

I have a hard time making that reading, specially since the
introduction to the bullet list says: "If any of the following
conditions hold..." -- making the condition sufficient on its own, but
not necessary.

> If we try to make determination of IP address belonging to a given AS
> mandatory, I think we are opening a can of worms, since although RPKI
> deployment has made a lot of progress, it’s far from universal. I think we
> are better off leaving this as written, IMO.

I agree that "belonging" should not be mandatory/part of the criteria
here.  Look at the 5th introductory point in my review.

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 May 2020 11:28:43 -0700

On May 4, 2020 at 4:50:36 PM, John Scudder wrote:

John:

Hi!

> You’re referring to this paragraph in section 11?

Yes, I think so.

> I’m inclined to agree with you that it covers the same ground. There is
> one difference, though: the section 11 paragraph is conditioned on the
> second paragraph of section 5:
>

This is the comment I wrote related to the §11 text:

   [major] "...one exception...a BGP UPDATE whose AFI/SAFI is...listed
   in...Section 5, if a TLV contains a malformed Tunnel Endpoint
   sub-TLV...the entire TLV MUST be ignored, and MUST be removed from the
   Tunnel Encapsulation attribute"   So...the "exception" applies to all the
   currently supported AFI/SAFIs...  If no other AFI/SAFIs are specified at
   this time, why is this "exception" not the norm?

ISTM that §3.1 says the same thing as the "exception" in §11: remove
the TLV.   But the general part of §11 is saying treat as
unrecognized.

> So the section 3.1 language you quoted could be considered to mean
> something just slightly different. Options I can think of include:
>
> - Ditch the section 3.1 language anyway, it’s close enough and besides
> section 5 says that all other AFI/SAFI are “beyond the scope of this
> document”.

I think we should remove the text in §3.1 because (at best) it is redundant.

The text in §11 needs to be clarified.

I think that's closer to #1...but it all depends on what is the
expected behavior: the one specified as normal, or the exception.

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 May 2020 11:31:49 -0700

Yeah…I think you’re right.

Thanks!

Alvaro.

On May 7, 2020 at 2:51:22 PM, John Scudder ([email-masked]) wrote:

Hi Alvaro,

—John