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

[Alvaro Retana <[e-mail]>]

On July 16, 2020 at 8:54:11 PM, John Scudder wrote:


John:

Hi!


> (And note that I’m replying as a co-author now.)

Thanks for taking the lead on this document!


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


[major] The reference to rfc5640 should be Informative.


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

[] 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.


...
> > [nit] s/encapsulation sub-TLV/Encapsulation sub-TLV/g

[] Some of these are still in the text.


...
> > 1054 4.2. Router's MAC Extended Community

[] We've been talking about this section in a separate message...


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



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


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



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