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

[Alvaro Retana <[e-mail]>]

On September 11, 2020 at 3:47:43 PM, John Scudder wrote:


John:

Hi!

I also only have a few comments...and a single actionable change
related to the optional nature of §3.1.1.

Both changes (this one, and the one in my other message) should not
gate the next step, so I'm starting the IETF LC.  I will want an
updated draft before going to the IESG, but we can bundle any
LC/Directorate review changes in it.

Thanks for the work and the discussion!! :-)

Alvaro.


...
> > 425 If the Address Family subfield contains the value for IPv4, the
> > 426 address subfield MUST contain an IPv4 address (a /32 IPv4 prefix).
> >
> > 428 If the Address Family subfield contains the value for IPv6, the
> > 429 address subfield MUST contain an IPv6 address (a /128 IPv6 prefix).
> >
> > [major] What should the receiver do if the address is not a host prefix?
>
> Let’s consider the possibilities. Keep in mind there’s no length field for
> the address field, so it has to be 4 or 16 octets. (That is, it’s not
> really a prefix except in the pedantic sense that a /32 or a /128 is a
> “prefix” that covers the entire address.) If the sender put in too many
> octets, or too few, it’s a simple length error, and the action is already
> specified. If the sender put in the right number of octets, but the content
> is nonsense, the nonsense might be so nonsensical that it fails the
> special-purpose registry (i.e., Martian) check, which is again a covered
> case. If the nonsense is syntactically ok enough, but it’s not currently
> forwardable, then the tunnel wouldn’t be considered feasible, which we’ve
> already discussed at length. If the nonsense just happens to be a feasible
> host route, it’s a little hard to call it “nonsense”. I can’t think of any
> other “not a host prefix” cases. So, I think this is already covered in the
> document.

I'm thinking of the case where the contents is a 32/128 bit number,
which happens to be forwardable, but which is not a host route.  For
example, 1.1.1.0: it is a 4 octet number, it is not a Martian, it is
forwardable, it can be resolved in a table, etc..  But it is not a
host route.

Hmmm...looking at the text again, it doesn't mention a "host prefix",
just a /32 or /128 prefix...which I guess doesn't have to be a host as
in identifying a single address.

So, I think we're good. ;-)



...
> > 468 o The IP address in the sub-TLV's address subfield is listed in the
> > 469 relevant Special-Purpose IP Address Registry [RFC6890] as either
> > 470 not a valid destination, or not forwardable.
> >
> > [] I don't think that pointing at what is listed in a registry is the
> > best. Suggestion:
> >
> > The IP address in the sub-TLV's address subfield is either not
> > Forwardable or not a valid Destination as defined in the Special-Purpose
> > Address Registries [RFC6890].
>
> I disagree. RFC 6890 has two relevant categories: “destination” can be true
> or false, and “forwardable” can be true or false. Our text is not talking
> about whether we have a forwarding route for the address, that’s dealt with
> in the feasibility condition. The text is talking about whether, according
> to RFC 6890, the address is a Martian, and the term RFC 6890 chose to use
> for this is “forwardable". I’ve tentatively rewritten as "The IP address in
> the sub-TLV's address subfield lies within a block listed in the relevant
> Special-Purpose IP Address Registry [RFC6890] with either a “destination”
> attribute value or a “forwardable” attribute value of “false”. (Such routes
> are sometimes colloquially known as “Martians".)” The new text is more
> ponderous but hopefully even less ambiguous.


I think that both pieces of text say pretty much the same thing, but
we chose slightly different words.  Note that rfc6890 specifically
uses Destination/Forwardable as keywords (instead of
"destination"/"forwardable").  In any case, we can keep the current
text.



...
> > 489 3.1.1. Validating the Address Field
...
> > [major] "a procedure that MAY be applied" If a sub-TLV is considered
> > malformed, then there are mandatory actions to be taken (§12). Making
> > this procedure optional creates a Normative conflict. IOW, if the
> > process is optional then the criteria should not be used to determine
> > if the sub-TLV is malformed...if some implementations do it this way
> > and other don't, or chose something different then the behavior
> > becomes non-deterministic.
> >
> > I made a similar comment before:
> >
> >>> [major] "one way" I hope that it is the MTI way -- otherwise, the
> >>> determination of the sub-TLV being malformed is not deterministic.
> >
> > ...and your answer...
> >
> >> This is not relevant any more, however 3.1.1 as written is optional, so
> >> not “MTI". I don’t think it’s non-deterministic, though — you either do
> >> it as written, or you don’t.
> >
> > Of course...you either do it or don't...
> >
> > However, it introduces potential interoperability issues: given the
> > same information, the actions of two different routers may be
> > different.
>
> I’m having a hard time accepting that this is a major issue. Yes, routers
> with different feature sets may exhibit different behaviors when presented
> with the same inputs. This has always been true and will always be true....

Point taken.

As I've said before, what really bothers me here is that there are
mandatory actions specified if the sub-TLV is malformed...but this
check is optional.  The real source of my issue is that §3.1 includes
the list of conditions to consider the sub-TLV malformed, and it
includes this one:

   o  It can be determined according to the procedures below
      (Section 3.1.1) that the IP address in the sub-TLV's address
      subfield does not belong to the Autonomous System (AS) that
      originated the route that contains the attribute.

I read this text as expecting §3.1.1 to be used.

NEW (aligning with §12 too)>

   o  It can be determined that the IP address in the sub-TLV's address
      subfield does not belong to the Autonomous System (AS) that originated
      the route that contains the attribute.  Section 3.1.1 describes an
      optional procedure.



...
> > [minor] s/UNLESS/unless
> > That is not a recognized key word.
>
> I changed it. (Is there some actual mandate that words can’t be in all caps
> unless they’re RFC 2119 keywords? RFC 2119 itself doesn’t say so.)

I'm not sure.  I've seen the RFC Editor correct the case too many
times...and some of the other ADs point it out consistently.  I took a
quick look at rfc7322, but didn't see anything about it...