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

[John Scudder <[e-mail]>]

On Aug 4, 2020, at 4:01 PM, Alvaro Retana <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> On July 16, 2020 at 8:54:11 PM, John Scudder wrote:
> 
> 
> John:
> 
> Hi!

Hi!

>> (And note that I’m replying as a co-author now.)
> 
> Thanks for taking the lead on this document!

You’re welcome.

> ...
>> I found a number of overlooked points as I worked through this reply, so
>> we’ve issued -17 to correct them. This reply is with respect to that
>> version.
> 
> I made some comments/replies below.  And I also made some comments
> in-line in -17 (sent separately); in some cases that seemed clearer.

I’ll reply separately to each review.

> 
> 
> I still have issues with "belonging" and reachability...specially in
> the case of multiple routing tables.  The Scoping section mentions
> that "it is intended that the Tunnel Encapsulation attribute be used
> only within a well-defined scope".  This makes me think: if the scope
> is well-defined (specially in the case of common administration), then
> some of the checks ("belonging", for example) could be easily avoided
> by configuration (policy)...and others (reachability) would be easier
> to constrain.  As I read through the document I can't help but think
> of the general case -- in part because of the transitivity, but also
> because the intended scope is not called out until much later.
> Consider moving the Scoping section closer to the start...and then
> defining some of the behavior in that context.  The intended use is
> just that, "intended", so the general operation will still have to be
> considered, but the normative pieces may become easier to specify.
> 
> [I hope that made sense...]
> 
> 
> 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”.

> [major] The reference to rfc5640 should be Informative.

Done.

> ...
>>> (4) Use Cases
>>> 
>>> rfc5512 gave an overview of the use case (mostly intra-AS), but this
>>> document doesn't mention use cases either as an introduction to the
>>> problem being solved or in the form of Operational Considerations.
>>> Sections 9 and 10 would be a good start for that type of section, but
>>> having a general description of the problem upfront (in the
>>> Introduction maybe) would be ideal. Again, because this document
>>> Obsoletes rfc5512, then we can't really rely on the information there.
>>> I'm looking for a few paragraphs, mostly directed at readers that may
>>> not be familiar with rfc5512 and the potential applications.
>> 
>> Added Section 1.4, "Use Case for The Tunnel Encapsulation Attribute”.
> 
> [] Consider moving this new section towards the front so the
> motivation is before the text about the changes.

Done; exchanged positions of 1.3 and 1.4.

> [] I also put some inline comments in -17.
> 
> 
> 
>>> (5) When does an IP address "belong" to an AS?
> ...
>> This is completely redone. See Section 3.1.1, “Validating the Address
>> Field”.
> 
> [] The text is now better...but I think some work is still needed in
> terms of clarity (I put comments inline in -17).
> 
> 
> ...
>>> [minor] rfc4271 consistency: s/best path/best route/g
> 
> [] There are a couple of these remaining.

Fixed.

> ...
>>> [nit] s/encapsulation sub-TLV/Encapsulation sub-TLV/g
> 
> [] Some of these are still in the text.

Fixed.

> ...
>>> 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”.

> 
> 
> ...
>>> 1080 5. Semantics and Usage of the Tunnel Encapsulation attribute
> ...
>>> 1135 * The tunnel is specified in a TLV whose Tunnel Endpoint sub-TLV
>>> 1136 identifies an IP address that is reachable.
>>> 
>>> [major] How is reachability determined? Where (which table) should
>>> the address be looked up in? In the sequence above, the destination
>>> address of P and the address of the endpoint may be resolvable in
>>> different tables...
>> 
>> Now says:
>> 
>> * The tunnel is specified in a TLV whose Tunnel Egress Endpoint
>> sub-TLV identifies an IP address that is reachable. This IP
>> address may be reachable via one or more forwarding tables.
>> Local policy may determine these forwarding tables and is
>> outside the scope of this document. The reachability condition
>> is evaluated as per [RFC4271].
> 
> The very next sentence says: "Then router R MUST send packet P through
> one of the feasible tunnels..."   This creates a big problem: the
> normative action depends on the feasibility of the tunnel, which
> depends on the reachability of the IP address -- but the mechanism to
> verify that is out of scope. :-(
> 
> How does R know that it is doing the right thing?
> 
>>> [BTW, please also take a look at
>>> draft-ietf-idr-bgp-bestpath-selection-criteria, which I think tries to
>>> define a related, if not the same, concept.]
> 
> I find myself in a quandary:
> 
> - On one hand, the WG has already recognized that clarifying the
> selection criteria is important, specially in the case of multiple
> possible tables.  It did this by requesting publication of
> draft-ietf-idr-bgp-bestpath-selection-criteria.  Ideally we could just
> reference that document here...but if it doesn't progress then we're
> stuck with a Normative reference...
> 
> - OTOH, we can pretend that rfc4271 is clear -- or at least that a
> document will eventually Update it...and not mention what that
> document may be...while knowing that rfc4271 doesn't provide any
> guidance and thus leaving the specification incomplete...
> 
> <sigh>
> 
> 
> draft-ietf-idr-bgp-bestpath-selection-criteria also talks about
> policy...but provides no specifics.  Can you at least provide
> information about possible policies and their effect?

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.

> 
> 
> 
> ...
>>> 1198 If a Tunnel Encapsulation attribute specifies several tunnels, the
>>> 1199 way in which a router chooses which one to use is a matter of policy,
>>> 1200 subject to the following constraint: if a router can determine that a
>>> 1201 given tunnel is not functional, it MUST NOT use that tunnel. In
>>> 1202 particular, if the tunnel is identified in a TLV that has a Tunnel
>>> 1203 Endpoint sub-TLV, and if the IP address specified in the sub-TLV is
>>> 1204 not reachable from router R, then the tunnel MUST be considered non-
>>> 1205 functional. Other means of determining whether a given tunnel is
>>> 1206 functional MAY be used; specification of such means is outside the
>>> 1207 scope of this specification. Of course, if a non-functional tunnel
>>> 1208 later becomes functional, router R SHOULD reevaluate its choice of
>>> 1209 tunnels.
>>> 
>>> [major] "not functional" What does that mean? How can that be
>>> determined? Is a "functional" tunnel the same as "feasible tunnel"
>>> (from earlier in this section)? If so, please use consistent
>>> terminology.
>> 
>> Now says:
>> 
>> If a Tunnel Encapsulation attribute specifies several tunnels, the
>> way in which a router chooses which one to use is a matter of policy,
>> In addition to the reachability to the address of the egress endpoint
>> of the tunnel, other policy factors MAY be used to determine the
>> feasibility of the tunnel. The policy factors are beyond the scope
>> of this document.
> 
> [major] This same section lists 3 conditions for feasibility...and a
> required action (MUST...) following.  This new text adds optional
> extra conditions to the feasibility, creating a Normative
> inconsistency.
> 
> Maybe "Then router R MUST send packet P..." can be softened (SHOULD),
> and the information in this paragraph can be moved closer to better
> position the exception.  Note that the paragraph immediately after
> "Then router R MUST send packet P..." already talks about local policy
> to select between tunnels, so there's some redundancy that should be
> eliminated.

I changed the three criteria for feasibility to four, the last one being "There is no local policy that prevents the use of the tunnel.” And, you are right that the quoted paragraph is redundant with the earlier one. I’ve eliminated the later one.

> 
> 
>>> [major] The paragraph specifies the same thing as about 6-7 paragraphs
>>> above (but calling it feasible). Please specify things only once.
>>> IOW, this paragraph seems redundant (if functional and feasible are in
>>> fact the same thing).
>> 
>> I think this is resolved now.
> 
> The difference is the use of normative language...

It’s not clear to me if you’re saying there’s another outstanding issue, beyond what’s discussed above. I’m going to assume there isn’t.

> 
> 
> 
> ...
>>> 1459 9. Applicability Restrictions
> ...
> 
> I appreciate the changes in this section...  Everything you wrote in
> the document and here is true: there's no substitute for good design,
> and anything can go wrong.  I'm thinking about the overall value of
> this section...I'm ok leaving it, it just feels like it doesn't say
> much that is not covered in the Security Considerations (for example).

OK.

—John