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

From: <[email-masked]>
Date: Thu, 4 Mar 2021 17:45:28 +0000

Dear WG,

We received very few support and review so far: two reviews excluding the authors and including the shepherd.
Thanks Greg for the review.

To allow for more feedback, the WG last call is extended for two weeks until March 18.

In the meantime, authors are invited to reply to the comments sent on the list.

Thanks,
--Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 9, 2021 7:31 PM
To: [email-masked]
Cc: [email-masked]
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.

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 8 Mar 2021 09:25:53 +0000

Hi,

I have read the draft and support the publication.

Thanks,
Shunwan

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 10, 2021 2:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear WG,

Thanks!

--Bruno

Thank you.

---

From: Huzhibo <[email-masked]>
Date: Mon, 8 Mar 2021 11:57:20 +0000

Hi,

Thanks,
Zhibo

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 5, 2021 1:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear WG,

Thanks,
--Bruno

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

Dear WG,

Thanks!

--Bruno

Thank you.

Thank you.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 12 Mar 2021 00:14:34 +0000

I have read the draft. I think it is very useful to have a solution that integrates the Network Server Header and the Segment routing.

I support the publication.

Linda Dunbar

Dear WG,

Thanks!

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-nsh-sr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C810b29e52e2d4d6c694008d8e21439c5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637507923815289125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FDX50G52uv%2BON5wiuxGYy5n4DSIvYY5CLomkngoMylU%3D&reserved=0>

--Bruno

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 15 Mar 2021 09:45:04 +0000

Hi Bruno,

I've read this document and support its publication.

Best regards,
Jie

Dear WG,

Thanks,
--Bruno

Dear WG,

Thanks!

--Bruno

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 15 Mar 2021 15:44:10 +0000

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

Dear WG,

Thanks!

--Bruno

Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 15 Mar 2021 23:57:27 +0800

Hi，
I support the publication. It describes the solution to support SFC by the integration of NSH and SR. It is useful. 

Best regards,
Cong
From: [email-masked]
Date: 2021-03-05 01:45
To: [email-masked]
CC: [email-masked]
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr
Dear WG,

 
 
Thanks,
--Bruno

Dear WG, 

 

Note that I’ll forward that call to the SFC WG.
 
Thanks!

--Bruno
 
_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent doncpas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signalera 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.

---

From: "Chongfeng Xie" <[email-masked]>
Date: Tue, 16 Mar 2021 12:35:51 +0800

Hello, folks,
I support this document to progress to IESG. 

Best regards
Chongfeng

[email-masked]

 

Thanks,
--Bruno

Dear WG, 

 

 
Thanks!

--Bruno

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Tue, 16 Mar 2021 08:37:22 +0000

Hi WG,

I have read this draft, and believe it is technique sound and well-written. I support to move it forward.

BRs,
Fan

发件人: spring [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2021年3月5日 1:45
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear WG,

Thanks,
--Bruno

Dear WG,

Thanks!

--Bruno

Thank you.

Thank you.

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Wed, 17 Mar 2021 08:27:07 +0000

Hi all,

I have read this document and support the publication.

Best regards,
Pang Ran.

From: [email-masked]<mailto:[email-masked]>
Date: 2021-03-05 01:45
To: [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr
Dear WG,

Thanks,
--Bruno

Dear WG,

Thanks!

--Bruno

Thank you.

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 17 Mar 2021 19:49:39 +0530

Hi WG,

I support the publication of this I-D. A few comments -

- Section 2
   A classifier SHOULD assign an NSH Service Path Identifier (SPI) per
   SR policy so that different traffic flows that use the same NSH
   Service Function Path (SFP) but different SR policy can coexist on
   the same SFP without conflict during SFF processing.

Why not MUST?

- Section 4, I suggest adding some recommendations related to the cache?
How long to keep (aging)? What happens in case of a cache miss? Should
these be set by the operator? Would be good from an operational point of
view to provide some more details related to caching.

- Section 4,

   The behavior of remembering the SR stack occurs at the end of the
   regularly defined logic.  The behavior of reattaching the stack
   occurs before the SR process of forwarding the packet to the next
   entry in the segment-list.  Both behaviors are further detailed in
   section 5.

The SR stack reads as SR-MPLS specific. Can this be generalized or perhaps
text added for SRv6 as well?

- Section 5, path-id is not used anywhere else; should it be mentioned that
this is Service Path Identifier (SPI)?

- Suggest adding a backward compatibility section to describe what is
likely to happen if an SFF does not support "Integrated NSH Service Plane"
but receives an NSHoSR packet.

Nits
- Remove references in the Abstract
- Should there be some reference to 3GPP in the first paragraph Section
1.1?
- Section 5, s/RFC 8754/[RFC8754]

Note
- There are 2 cases of Normative reference to Informational RFCs: RFC 8596
and 7665. Need to handle Downref registry during IETF LC.

Thanks!
Dhruv

On Thu, Mar 4, 2021 at 11:15 PM <[email-masked]> wrote:

> *From**:* spring [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Tuesday, February 9, 2021 7:31 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [spring] WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Dear WG,
>
>
>
> 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.
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>