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

[Susan Hares <[e-mail]>]

John and Alvaro: 

Do you want me to do a complete new shepherd review at this point?  

Cheers, Sue 

-----Original Message-----
From: Alvaro Retana [mailto:[e-mail]] 
Sent: Thursday, September 17, 2020 6:18 PM
To: John Scudder
Cc: [e-mail]; idr@ietf. org; [e-mail]
Subject: Re: AD Review of draft-ietf-idr-tunnel-encaps-15

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.