Re: [Idr] Erik Kline's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Erik,

Thanks for your review. My comments in line below.

> On Dec 1, 2020, at 12:29 AM, Erik Kline via Datatracker <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-idr-tunnel-encaps-20: Discuss
> 
> 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!T5wpPlhK57FvqcPz4kxiPKl9SWUsD7eakk297sqQMU5TlAQ5F31ILhn736iHxQ$
> 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!T5wpPlhK57FvqcPz4kxiPKl9SWUsD7eakk297sqQMU5TlAQ5F31ILhnQzyDIKg$
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> [ section 3.3.1 ]
> 
> * The text about "[a]ny one-octet value can be transported" leaves me
>  wondering about how values that result in ECN bits being set should be
>  treated.
> 
>  I think there needs to be some recognition here that the DSCP part of
>  the octet is only 6 bits (2474 section 3), and that bits 6 & 7 "MUST/SHOULD
>  be zero on transmission and MUST/SHOULD be ignored by the recipient".
> 
>  Another way to ask the question here is: if ECN is not to be specified as
>  part of this octet (and IMHO it should not be), which ranges of 6 bit
>  values are permitted: [0..63], with the understanding this will be shifted
>  before setting the octet, or [0,4,8,12,...,252]?  Given the text "It
>  specifies the setting of the one-octet...", I think it implies the latter,
>  but some clarification would, I think, be helpful.

Replied separately.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ questions ]]
> 
> [ section 3.1 ]
> 
> * The prohibition against use of Forwardable=false egress IPs I think means
>  that IPv4 and IPv6 link-local addresses cannot be used.  It seems somewhat
>  unusual, but not completely outside the realm of reasonable, to have a
>  situation where two on-link routers could be configured by their respective
>  administrators to use some encapsulation for forwarded packets without
>  having to resort to global unicast addresses.
> 
>  Are we sure this (odd) use case should be prohibited?

Nope! How about we add this sentence to that bullet item: “This restriction MAY be relaxed by explicit configuration.”

>  The final paragraph of this section seems to cover the use of non-reachable
>  addresses just fine.  Obviously link-local IPs would need to be exempt from
>  section 3.1.1 AS-owned address validation.

I think 3.1.1 would work OK, actually, since the forwarding route would have no AS associated with it, and "If no AS Path is encounteredat all, for example if that route's source is a protocol other than BGP, the Route Origin ASN is the BGP speaker's own AS number."

> [ section 3.3+ ]
> 
> * Do any implementations wish to set IPv6 flow labels?

Not that I’ve been told of; see my reply to Éric.

> [ section 6 ]
> 
> * Might MTU overhead a consideration in tunnel selection?  I.e., given more
>  than one tunnel option might an implementation choose based on minimizing
>  total overhead?

Seems reasonable. Tunnel selection is a matter of local policy of course:

   If the Tunnel Encapsulation attribute contains several TLVs (i.e., if
   it specifies several feasible tunnels), router R may choose any one
   of those tunnels, based upon local policy.

Then again we do make mention of two possible factors that could influence selection:

   If any Tunnel TLV
   contains one or more Color sub-TLVs (Section 3.4.2) and/or the
   Protocol Type sub-TLV (Section 3.4.1), the choice of tunnel may be
   influenced by these sub-TLVs.

I’d be fine with adding a mention of MTU if you think it useful, e.g. adding a sentence like “Many other factors, for example minimization of encapsulation header overhead, could also be used to influence selection.”

Regards,

—John