Re: [Idr] Martin Duke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)

[John Scudder <[e-mail]>]

Hi Martin,

Thanks for your comments. My reply below.

> On Dec 1, 2020, at 4:24 PM, Martin Duke via Datatracker <[e-mail]> wrote:
> 
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-idr-tunnel-encaps-20: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!QklZWO1xCRxZ4O7wK1p08p_1D6hWjTNv8NPa5CIWIg77_enYzU0Ibeo9MLhzGw$
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/__;!!NEt6yMaO-gk!QklZWO1xCRxZ4O7wK1p08p_1D6hWjTNv8NPa5CIWIg77_enYzU0IbeqaXPvvBA$
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Erik's DISCUSS.
> 
> Thank you for Section 1.3; it was extremely helpful to understand what this
> spec is trying to accomplish.
> 
> In Sec 3.1 it says there MUST be exactly one Tunnel Egress Endpoint sub-TLV but
> describes an error if there are zero sub-TLVs. In Sec 13 this is correctly
> specified as anything other than 1 sub-TLV. Please update 3.1 to match.

Before I edit anything, let me make sure I properly understand your comment. I agree there’s a small, but real, disconnect between 3.1 and 13, but I don’t think it’s exactly as you’ve written.

Here’s the text from 3.1:

   When the Tunnel Encapsulation attribute is carried in an UPDATE
   message of one of the AFI/SAFIs specified in this document (see the
   second paragraph of Section 6), each TLV MUST have one, and one only,
   Tunnel Egress Endpoint sub-TLV.  If a TLV does not have a Tunnel
   Egress Endpoint sub-TLV, that TLV should be treated as if it had a
   malformed Tunnel Egress Endpoint sub-TLV (see below).

The “and one only” is at variance with this paragraph in Section 13, which says:

   The following sub-TLVs defined in this document MUST NOT occur more
   than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed
   below), Encapsulation, DS, UDP Destination Port, Embedded Label
   Handling, MPLS Label Stack, Prefix-SID.  If a Tunnel TLV has more
   than one of any of these sub-TLVs, all but the first occurrence of
   each such sub-TLV type MUST be disregarded.  However, the Tunnel TLV
   containing them MUST NOT be considered to be malformed, and all the
   sub-TLVs MUST be propagated if the route carrying the Tunnel
   Encapsulation attribute is propagated.

That says that you can actually stuff as many Tunnel Egress Endpoint sub-TLVs as you like in, and the receiver is just supposed to disregard the extras. Now, since the extras are disregarded, we can argue that there’s still “one only” for practical purposes, but I’ll grant there’s a shadow of difference.

Then later in 13 we have:

   In general, if a TLV contains a sub-TLV that is malformed, the sub-
   TLV MUST be treated as if it were an unrecognized sub-TLV.  This
   document specifies one exception to this rule -- if a TLV contains a
   malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1),
   the entire TLV MUST be ignored, and MUST be removed from the Tunnel
   Encapsulation attribute before the route carrying that attribute is
   distributed.

   Within a Tunnel Encapsulation attribute that is carried by a BGP
   UPDATE whose AFI/SAFI is one of those explicitly listed in the second
   paragraph of Section 6, a TLV that does not contain exactly one
   Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a
   malformed Tunnel Egress Endpoint sub-TLV.

Taken together, those paragraphs say exactly the same thing as what’s in 3.1 — 3.1 says “one, and one only” and the above paragraphs say “exactly one” but I think we can agree that’s the same thing. And 3.1 says “treated as if it had a malformed…” whereas the first of the two paragraphs quoted above says what action to take in that case, namely to ignore and remove the containing TLV. 

So I think we have a few problems to fix:

First, the redundancy between 3.1 and 13 is annoying and a source of potential confusion. I may have previously defended keeping the 3.1 text (it’s nice for an implementor to have useful information like “there’s exactly one of these things” right next to the definition of the sub-TLV) but now I’m increasingly convinced that it’s more of a liability than a benefit, and propose removing it from 3.1 and just supplying a forward reference.

Second, there’s a contradiction between the first paragraph I quoted from 13, that says multiple occurrences of the sub-TLV are handled by ignoring the repeats, and the third one I quoted, that says multiple occurrences are handled by the much more draconian procedure of dropping the offending tunnel TLV altogether. I think we should pick one, probably the more draconian version, and make the section consistent.

Thanks for calling attention to this dissonance.

—John