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

[Bob Briscoe <[e-mail]>]

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]>
> *Date: *Friday, 1 December 2023 at 22:56
> *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, 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/