Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

[[e-mail]]

Hi authors, SPRING,

Speaking as shepherd.

Encapsulation of NSH following SRv6 may be indicated either by
   encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the
   Next Header field of the SRH, or by indicating an IP protocol number
   for NSH in the Next Header of the SRH."


Yes, NSH may be encapsulated using a variety of ways. But did we had a discussion about why we need to specify both?
A priori, having N ways increase the cost and decrease the interoperability.

More specifically, why do we need to add the UDP layer?
- This increases the packet overhead
- In IPv4, UDP may be a solution to cross NAT-PT, but for IPv6 this looks less likely. Plus the use case would likely have NAT as a Service Function, not between Service Functions
- In IPv4, UDP may be a solution to provide entropy for ECMP. But in IPv6 & SRv6, we already have the flow label.
- The use of UDP is likely to require an additional section and discussion (from Transport Area) regarding congestion.

Thanks,
Regards,
--Bruno


From: spring [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, February 9, 2021 7:31 PM
To: [e-mail]
Cc: [e-mail]
Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear WG,

This message starts a 2 weeks WG last call for draft-ietf-spring-nsh-sr [1].

After review of the document please indicate whether you believe this document should be progressed to the IESG.

In addition to yes/no, please consider providing a technical review of this document; in particular if you care for this document.
Indeed, since WG adoption, this document had benefited from little reviews from the WG, so we need more review from the SPRING WG.

If you are aware of an implementation of this document, please report the implementation either on the list or to the chairs so that the shepherd can report implementations in the writeup.

Note that I'll forward that call to the SFC WG.

Thanks!

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr

--Bruno


_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.