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

[John Scudder <[e-mail]>]

WG: at some point in the course of working through Alvaro’s review, my shepherd hat fell off my head and an author hat fell on :-o So, Sue will be taking over as shepherd and responsible co-chair. This note is with my co-author hat on.

Hi Alvaro,

As you know I’ve been working with the authors to update the document per your comprehensive review (for which, thanks). The new version should be out shortly; below one response on a comment we didn’t choose to address with a change:

> On Feb 21, 2020, at 7:47 AM, Alvaro Retana <[e-mail]> wrote:
...
> 934	3.7.  Prefix-SID Sub-TLV
...
> 947	   The Prefix-SID sub-TLV can occur in a TLV identifying any type of
> 948	   tunnel.  If an Originator SRGB is specified in the sub-TLV, that SRGB
> 949	   MUST be interpreted to be the SRGB used by the tunnel's egress
> 950	   endpoint.  The Label-Index, if present, is the Segment Routing SID
> 951	   that the tunnel's egress endpoint uses to represent the prefix
> 952	   appearing in the NLRI field of the BGP UPDATE to which the Tunnel
> 953	   Encapsulation attribute is attached.
> 
> [major] Except for the first sentence, this paragraph says the same
> thing as rfc8669.  Please don't re-specify the behavior here (unless
> it changes, of course); instead, point at the source.

The quoted paragraph talks about how the Prefix-SID Sub-TLV is to be interpreted, in relation to terms defined in RFC 8669. RFC 8669 is — of course — the authority regarding what those things mean, but tunnel-encaps has to tell the implementor how to map the fields in the sub-TLV into the constructs defined in 8669. It may seem obvious that the fields relate to “the tunnel’s egress endpoint” but it still seem better to say so than to leave it up to the creativity of the implementor. So, I don’t think tunnel-encaps is re-specifying at all. We’ve let the paragraph stand as written.

Thanks,

—John