From nobody Wed Mar 17 07:20:21 2021 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B421B3A0D27; Wed, 17 Mar 2021 07:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSLWxK5CeBJL; Wed, 17 Mar 2021 07:20:17 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C513A0D20; Wed, 17 Mar 2021 07:20:17 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id n14so41146890iog.3; Wed, 17 Mar 2021 07:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fu2PP6qi+Ir90iRxjQa40UrOy2EmiX2lms17I3DnppM=; b=Gl6BrKP8pwZh2xCEgeTVK5Ei9BSOccaW8mGWONxhKP8QoAQJ5iJpseIuTe8sqcEI5R H4qnIwGMngA0EN1TnQ3z+5dK2EaF161JgiHfL83YePCTRRPsb8bG6mvAseXTgjNJ0dgX NiDW3eV1QhvXCQOt0AkunKXS3kBWi5MjfHZXENkvy/LYOvBKGuZZei68UpCqA3bYeZ0G 3zXF/nEHJBR/Cf92aF3+O+TreO4YizZ1tCeLD9i1p82sUhz+1e7HIhcq87JPvJQjwFse hv8/hYgn5sxBSXYqYckYMlM3GYu4xcHi8uAHyPhDN+cbisMM8k31LSVJ1WI6cszUl12Z pKEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fu2PP6qi+Ir90iRxjQa40UrOy2EmiX2lms17I3DnppM=; b=H7r1V2p/iWeOBwh78tZawS02NlNAgq+INtsyFonGViRfnGFW3RlygY9gnCis12GBL2 8UNDwdYB8lvikXFltMxGQBWs6Q8Jqb8fcYZpmCXPXWz+oKul2YM82uzen1Q/wCWT9f+V bcSYXawLqcN8uL++48cffyvBxypo6aAmx671NDvLU4fDQH6lylFIUY3Zv2s3ymIh2190 PAWN+Ajs2KKtzlBh3Jsa3TdCLoDzBGFJ8QO4GuSTdLboNeU8altaDN4CAQx3ZxnLl0D1 xtnzUbfrfYX0mI9tV7w5PULnNoPNWG4l2WbbhWgx/y8JZ3cwHiIJMTtvweQGw1G0gs08 6ZjA== X-Gm-Message-State: AOAM530lhc0az1Q2TfH5yZAhppU1wkopKyR6X6U/IgKEKVu+5z0B80j7 Dcsvvnr0TMUbd4R3ja4HkuK2n57a/XHV+3oi0gnZWurrKCkR1w== X-Google-Smtp-Source: ABdhPJzmqsp1G6gxUR7B1mAVqa++hol5xDp1Y5Er0YgUOEKu0tHE7kdjir6g/eam3lyy4WLXveKv7BXKMPDXLUT7K2M= X-Received: by 2002:a05:6638:3399:: with SMTP id h25mr2954303jav.15.1615990815793; Wed, 17 Mar 2021 07:20:15 -0700 (PDT) MIME-Version: 1.0 References: <25012_1612895472_6022D4F0_25012_72_1_53C29892C857584299CBF5D05346208A490C4A3A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <21557_1614879929_60411CB8_21557_261_2_53C29892C857584299CBF5D05346208A4911361F@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <21557_1614879929_60411CB8_21557_261_2_53C29892C857584299CBF5D05346208A4911361F@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Dhruv Dhody Date: Wed, 17 Mar 2021 19:49:39 +0530 Message-ID: To: bruno.decraene@orange.com Cc: "spring@ietf.org" , "draft-ietf-spring-nsh-sr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008926d005bdbc2ee6" Archived-At: Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 14:20:20 -0000 --0000000000008926d005bdbc2ee6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > 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:spring-bounces@ietf.org] *On Behalf Of * > bruno.decraene@orange.com > *Sent:* Tuesday, February 9, 2021 7:31 PM > *To:* spring@ietf.org > *Cc:* draft-ietf-spring-nsh-sr@ietf.org > *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 review= s > 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 c= an > report implementations in the writeup. > > > > Note that I=E2=80=99ll 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 confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000008926d005bdbc2ee6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,=C2=A0

I support the p= ublication of this I-D. A few comments -=C2=A0

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

Why not MUST?

- Section 4, I suggest adding some recommenda= tions 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,

=C2=A0 =C2=A0The behavior of remembering the = SR stack occurs at the end of the
=C2=A0 =C2=A0regularly defined logic.= =C2=A0 The behavior of reattaching the stack
=C2=A0 =C2=A0occurs before = the SR process of forwarding the packet to the next
=C2=A0 =C2=A0entry i= n the segment-list.=C2=A0 Both behaviors are further detailed in
=C2=A0 = =C2=A0section 5.

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

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

- Suggest adding a backward c= ompatibility section to describe what is likely to happen if an SFF does no= t support "Integrated NSH Service Plane" but receives an NSHoSR p= acket. =C2=A0

Nits
- Remove references in the Abstract
- Shou= ld 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 Nor= mative reference to Informational RFCs: RFC 8596 and 7665. Need to handle D= ownref registry during IETF LC.

Thanks!=C2=A0
Dhruv=C2=A0

On Thu, Mar 4, 2021 at 11:15 PM <bruno.decraene@orange.com> wrote:

<= span style=3D"color:rgb(31,73,125)">Dear WG,

=C2=A0

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

= Thanks Greg for the review.

= =C2=A0

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

= =C2=A0

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

= =C2=A0

= Thanks,

= --Bruno

= =C2=A0

<= b>From: spring [mailto:spring-bounces@i= etf.org] On Behalf Of bruno.de= craene@orange.com
Sent: Tuesday, February 9, 2021 7:31 PM
To: spring@ietf= .org
Cc: draft-ietf-spring-nsh-sr@ietf.org
Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr

=C2=A0

Dear WG,

=C2=A0

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

=C2=A0

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

=C2=A0

In addition to yes/no, please c= onsider 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 re= view from the SPRING WG.

=C2=A0

If you are aware of an implemen= tation of this document, please report the implementation either on the lis= t or to the chairs so that the shepherd can report implementations in the w= riteup.

=C2=A0

Note that I=E2=80=99ll forward = that call to the SFC WG.

=C2=A0

Thanks!

=C2=A0

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

=C2=A0

--Bruno

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


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


they should not be distributed, used or copied without authorisation.<=
u>


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 confiden=
tielles 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 message=
s 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 inf=
ormation 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 dele=
te 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.
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000008926d005bdbc2ee6--