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

["Eric Vyncke (evyncke)" <[e-mail]>]

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]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[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 to https://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 in https://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 Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/