Re: [tsvwg] Éric Vyncke's Discuss on draft-ietf-tsvwg-rfc6040update-shim-21: (with DISCUSS and COMMENT)

[Bob Briscoe <[e-mail]>]

Eric, Thank you for your review. Pls see [BB] (where no comment on any 
point means accepted)...

On 28/11/2023 07:17, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-tsvwg-rfc6040update-shim-21: 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 tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> # Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-rfc6040update-shim-21
>
> Thank you for the work put into this document.
>
> Please find below one blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only for
> my own education), and some nits.
>
> Special thanks to Gorry Fairhurst for the shepherd's detailed write-up
> including the WG consensus *but it lacks* the justification of the intended
> status.
>
> Other thanks to Donald Eastlake, the Internet directorate reviewer (at my
> request), please consider this int-dir review:
> https://datatracker.ietf.org/doc/review-ietf-tsvwg-rfc6040update-shim-20-intdir-telechat-eastlake-2023-11-22/
> (and I have noticed Bob's reply)
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # DISCUSS (blocking)
>
> As noted inhttps://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion on the following topics:
>
> ## Wrong BCP14 ...
>
> Section 2 MUST use the correct BCP 14 (I told you that this was trivial)
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # COMMENTS (non-blocking)
>
> ## Section 3.1
>
> It is just a comment, no need to reply, but I do not agree with `Digging to
> arbitrary depths to find an inner IP header within an encapsulation is strictly
> a layering violation`, the encapsulating routing is probably doing the encaps
> based on the future inner IP header (routing to a tunnel interface). Anyway,
> just a comment.

[BB] I haven't changed this - I think the word 'strictly' conveys the 
message that this is actually done in practice, while "it cannot be a 
required behaviour" is reinforced by the later point that there always 
has to be a max depth to dig down to if you're not actually 
decapsulating headers but just digging to look.

> ## Section 6
>
> Suggest removing the long expired draft-ietf-intarea-gue (and possibly others).

[BB] Removed. Thx for being decisive on what is not going forward.

> Suggest to add RFC 8986 as it also has a Ethernet next-header.

[BB] I've scanned through RFC8986. Generally, it only /uses/ existing 
encapsulations. But you're right that §10.1 does assign 143 as the next 
header value for Ethernet. However, not having been involved in the area 
of L2VPNs, I don't understand how/why this happened so late (2021). IOW, 
how was Ethernet indicated as the next header in EVPNs before RFC8986? 
Was the EtherIP assignment used/abused? Whatever, this is just a request 
for a personal tutorial. Back to the draft....

I believe Ethernet L2VPNs are outside the scope of rfc6040update-shim. 
An Ethernet  802.3 MAC header does not fall under the definition of a 
shim header, 'cos it is self-sufficient as an outer for general 
forwarding. So an 802.3 header does not have to be added (or removed) at 
the same time as an outer IP header. And an Ethernet header cannot carry 
any form of explicit congestion notification {Note 1}.

Therefore, there's no sure way to be able to propagate ECN between a 
(possible) IP header encapsulated within the Ethernet header and an 
outer IP header encapsulating the Ethernet header. This could be 
specified, but it's certainly not just something we could tack on to 
rfc6040update-shim - it's beyond the stated scope - much more ambitious.

So, do you agree it is OK not to introduce SRv6? Or have I misunderstood?


{Note 1}: Other than 802.1Q in the control plane, but making that work 
over a L2VPN would be a whole new exercise in itself.

>
> ## Section 6.1.2
>
> Please note that NHRP, RFC 2332, is sometimes used to set up GRE tunnels.

[BB] I'm afraid NHRP is completely new to me. If I add it at the start 
of the list of 4 control plane protocols in the quote below (from 
"§6.1.2 GRE"), will the subsequent para still be correct, or is NHRP not 
used to set up IP-in-IP or IPSec tunnels?

    GRE itself does not support dynamic set-up and configuration of
    tunnels. However, control plane protocols such as *NHRP [RFC2332],*
    Mobile IPv4 (MIP4) [RFC5944
    <https://www.rfc-editor.org/info/rfc5944>], Mobile IPv6 (MIP6)
    [RFC6275 <https://www.rfc-editor.org/info/rfc6275>], Proxy Mobile IP
    (PMIP) [RFC5845 <https://www.rfc-editor.org/info/rfc5845>] and IKEv2
    [RFC7296 <https://www.rfc-editor.org/info/rfc7296>] are sometimes
    used to set up GRE tunnels dynamically.

    When these control protocols set up IP-in-IP or IPSec tunnels, it is
    likely that the resulting tunnels will propagate the ECN field as
    defined in RFC 6040 or one of its compatible predecessors (RFC 4301
    or the full functionality mode of RFC 3168). However, if they use a
    GRE encapsulation, this presumption is less sound.

Thanks again


Bob


>
> ## Section 6.1.3
>
> Teredo... a glimpse of the past back in 2023 ? More seriously, I do not mind
> having this section, but Teredo is no more used. Writing `existing Teredo
> deployments safe` in an IETF document looks so weird.
>
> # NITS (non-blocking / cosmetic)
>
> ## Use of v4 and v6
>
> While I usually say "v4" or "v6", I strongly suggest to write "IPv4" and "IPv6".
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/