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

[Alvaro Retana <[e-mail]>]

On September 11, 2020 at 11:25:31 AM, John Scudder wrote:

John:

Hi!

Just a couple of comments...  Just one actionable change related to
the reachability issue: you're right, we should move on.

Thanks!

Alvaro.



...
> > ...
> >> We added 5566 and 5640 to the list of obsoleted RFCs, along with an
> >> explanation.
> >
> > [major] The IANA assignments made for those RFCs need to be declared
> > obsolete in the IANA Considerations section.
>
> Is “obsolete” an IANA thing? I’ve added a subsection to the IANA section as
> requested, but asked them to mark the code points as “deprecated”.


Yes, "obsolete" is an IANA thing. rfc8126: "Specific entries in a
registry can be marked as "obsolete" (no longer in use) or
"deprecated" (use is not recommended)."

You used both terms in §13.1 to refer to the code points.  You're
right, deprecating is the right action, but IANA may be confused by
the use of both.  This is a minor point, so we can wait for them to
ask about it. :-)



...
> >>> 1054 4.2. Router's MAC Extended Community
> >
> > [] We've been talking about this section in a separate message...
>
> OK. To loop the WG in on the conclusion of that, it appears that
> draft-ietf-bess-evpn-inter-subnet-forwarding only allows a single Router’s
> MAC (authors have been asked to clarify) so assuming that’s right, we must
> pick one or the other if it’s encoded twice in two ways with different
> values. In -18 I’ve changed the text to say “use the EC” instead of the
> former “use the sub-TLV”.

FYI...

I have a DISCUSS on draft-ietf-bess-evpn-inter-subnet-forwarding
precisely due to the lack of sync with this document.  I hope that the
authors provide an answer and align with the changes here.




> >>> 1080 5. Semantics and Usage of the Tunnel Encapsulation attribute
...

> All of this is true. Basically, we can either hang progress of this
> document up for a potentially long time waiting for something that may
> never come: a detailed specification of exactly when a route is, and isn’t,
> resolvable, or we can admit it’s an imperfect world and move forward. I
> will observe that despite 4271’s lack of prescriptiveness, somehow we have
> many interoperable implementations of BGP. I suspect this is because when
> an implementor looks at route resolution, it’s a little like Justice Potter
> Stewart looking at other material: “[I can’t define it but] I know it when
> I see it.”
>
> I tried to make the paragraph clearer by adding a final clause. The last
> sentence now reads, "The reachability condition is evaluated as per
> [RFC4271], but the essence is that if the router could forward a packet
> addressed to the IP address, the IP address is "reachable”.” We could
> absolutely pick this short summary to shreds if we chose — see above. It’s
> not meant to be prescriptive, only descriptive.


Ok.

Let's go with an "intermediate" approach, so that we don't try to say
too much, but (hopefully) say enough:

NEW>
   *  The tunnel is specified in a TLV whose Tunnel Egress Endpoint sub-TLV
      identifies an IP address that is reachable.  The reachability condition
      is evaluated as per [RFC4271].  If the IP address is reachable via
      more than one forwarding table, local policy is used to determine
      which table to use.