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

[Bob Briscoe <[e-mail]>]

Eric,

Thanks. Given I believe everyone's comments have been addressed, I've 
just submitted a new rev, with the correct normative text boilerplate to 
clear your DISCUSS:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim#name-terminology

Cheers


Bob

On 05/12/2023 15:01, Eric Vyncke (evyncke) wrote:
>
> Bob
>
> Top replies:
>
> - thank you for clarifying “shim” in the context of this I-D
>
> - I confirm that NHRP is used to build GRE tunnels mesh
>
> Regards
>
> -éric
>
> *From: *Bob Briscoe <[e-mail]>
> *Date: *Tuesday, 5 December 2023 at 01:23
> *To: *Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [tsvwg] Éric Vyncke's Discuss on 
> draft-ietf-tsvwg-rfc6040update-shim-21: (with DISCUSS and COMMENT)
>
> Eric, pls see [BB2]
>
> On 04/12/2023 12:35, Eric Vyncke (evyncke) wrote:
>
>     Hello Bob,
>
>     Thanks for your reply.
>
>     See below for EV>
>
>     *From: *Bob Briscoe <[e-mail]> <mailto:[e-mail]>
>     *Date: *Friday, 1 December 2023 at 22:56
>     *To: *Eric Vyncke (evyncke) <[e-mail]>
>     <mailto:[e-mail]>, The IESG <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc: *[e-mail] <[e-mail]>
>     <mailto:[e-mail]>, [e-mail] <[e-mail]>
>     <mailto:[e-mail]>,
>     [e-mail]
>     <[e-mail]>
>     <mailto:[e-mail]>,
>     [e-mail] <[e-mail]>
>     <mailto:[e-mail]>, [e-mail]
>     <[e-mail]> <mailto:[e-mail]>
>     *Subject: *Re: [tsvwg] Éric Vyncke's Discuss on
>     draft-ietf-tsvwg-rfc6040update-shim-21: (with DISCUSS and COMMENT)
>
>     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)
>
>           
>
>           
>
>         EV> just to be clear, I am clearing my DISCUSS as soon as a
>         revised I-D is submitted with the right BCP14 template (you
>         probably have authored the I-D using an old template)
>
>         ----------------------------------------------------------------------
>
>         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.
>
>     EV> indeed, this was just a comment, feel really free to ignore it
>     (i.e., no change in the current text) as it is more a conversation
>     to have in front of a drink.
>
>           
>
>         ## 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....
>
>     EV> basic tutorial then ;-) with RFC 8986, there was no need for
>     yet-another-encapsulation (e.g., GENEVE, VXLAN) as it is already
>     in a tunnel. AFAIK, IP protocol 143 is only used by this RFC.
>
>
>
>     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?
>
>
>
>     EV> unsure why it is not a shim, but you are correct there is
>     probably no easy way to propagate ECN in this case. OTOH, skipping
>     the Ethernet header, find its Ethertype, and adjust the following
>     IPv4/IPv6 header (if any)
>
>
> [BB2] The definition of shim' (for this draft at least) is that it's 
> not a sufficient header to be used for forwarding on its own (as an 
> outer). This then requires an outer to be added to the shim at the 
> same location (because the shim isn't sufficient to forward the PDU to 
> anywhere else). Then even if header compression or encryption, etc. is 
> applied,  the inner header inside the shim(s) and the outer header 
> outside the shim(s) must both have been accessible at some part of the 
> process at one location. it's then likely there will be no difficulty 
> propagating the ECN field between inner & outer.
>
>
>
>     {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?
>
>     EV> NHRP is indeed often used to build GRE tunnels (themselves
>     protected by IPsec in transport mode), this was a common approach
>     before the controller-based SD-WAN paradigm
>
>         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.
>
>         EV> an Oxford comma is probably required before “and IKEv2”
>
>
>
>         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.
>
>
> [BB2] My question was whether NHRP is used to build these other 
> tunnels (IP-in-IP or IPSec). Because the phrase 'these control 
> protocols' refers to those in the previous list, which now includes 
> NHRP. Therefore I was checking if this last para is still correct.
>
> BTW, I leave the RFC Ed to add Oxford commas. My innate British 
> English writing style doesn't include them. So if I forced myself to 
> add them, it would just end up as an inconsistent mess.
>
> Cheers
>
>
>
> Bob
>
>
>
>     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/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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