Re: [ippm] [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Shwetha,

I agree with Frank and you that the text on Next Protocol should be as is, draft-xzlnp-bier-ioam uses the similar definition while encapsulating IOAM data in BIER.
Besides, I believe the main purpose is that multiple IOAM options can be carried in one NSH/BIER packet, even if only one IOAM namespace is deployed.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：ShwethaBhandari
收件人：Med Boucadair;
抄送人：James Guichard;sfc-chairs@ietf.org;sfc@ietf.org;ippm@ietf.org;
日 期 ：2022年04月27日 16:46
主 题 ：Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

Hi Med,
Thanks for the confirmation and quick review.

On,
This means the new requested TBD_IOAM value will also be a valid next protocol. However, I wonder whether IOAM in IOAM in NSH is really something you want to have. If not, I suggest the text is updated to exclude it from the allowed value in the above excerpt.
Per earlier discussion in this thread, quoting Frank's mail here for reference:
In addition, I don’t think that draft-ietf-sfc-ioam-nsh would be the appropriate place to discuss and restrict deployment options. E.g., I’m not sure why we’d want to restrict a deployment to using a single IOAM header only. E.g., one could think of using different headers for different namespaces or groups of namespaces for operational reasons. IMHO, such a discussion – if we really need it - would belong into draft-ietf-ippm-ioam-deployment, rather than into a draft that defines the encap of IOAM into NSH.
I think the text on Next Protocol should be as is. We should not add restrictions on number of IOAM headers that could be added to the packet.

Thanks,
Shwetha

On Wed, Apr 27, 2022 at 1:46 PM <mohamed.boucadair@orange.com> wrote:
Hi Shwetha, all,
The changes look great. Thanks.
There is one specific point not addressed in previous replies. This is related to this text:
Next Protocol:  8-bit unsigned integer that determines the type of
header following IOAM.  The semantics of this field are
identical to the Next Protocol field in [RFC8300].
This means the new requested TBD_IOAM value will also be a valid next protocol. However, I wonder whether IOAM in IOAM in NSH is really something you want to have. If not, I suggest the text is updated to exclude it from the allowed value in the above excerpt.
Other than that, I think that the draft is ready to move forward.
Cheers,
Med
De : Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Envoyé : mercredi 27 avril 2022 10:06
À : James Guichard <james.n.guichard@futurewei.com>; sfc-chairs@ietf.org
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>; sfc@ietf.org; ippm@ietf.org; Tal Mizrahi <tal.mizrahi.phd@gmail.com>; draft-ietf-sfc-ioam-nsh@ietf.org; Greg Mirsky <gregimirsky@gmail.com>
Objet : Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Dear SFC chairs,
A new version of the draft I-D.ietf-sfc-ioam-nsh has been submitted per the discussion in this thread.
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-09
Can we please progress this draft to IESG if there are no further comments?
Thanks,
Shwetha

On Thu, Apr 14, 2022 at 6:41 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Shwetha,
thank you for the proposed resolution. I agree with Med, direct normative reference to I-D.ietf-sfc-oam-packet seems like the logical conclusion of our discussion of the use of the NSH O bit. Please note that we're referring to I-D.ietf-sfc-oam-packet  in the Active SFC OAM draft, e.g.,:
The O bit in NSH MUST be set, according to [I-D.ietf-sfc-oam-packet].
Regards,
Greg

On Thu, Apr 14, 2022 at 4:27 AM <mohamed.boucadair@orange.com> wrote:
Hi Shwetha,
I prefer we go for an explicit reference to I-D.ietf-sfc-oam-packet rather than “any update to RFC8300”. This is consistent  with the usage in the other OAM draft.
Thank you.
Cheers,
Med
De : Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
Envoyé : jeudi 14 avril 2022 12:06
À : Greg Mirsky <gregimirsky@gmail.com>
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Frank Brockners (fbrockne) <fbrockne=40cisco.com@dmarc.ietf.org>; sfc-chairs@ietf.org;  sfc@ietf.org; ippm@ietf.org; James Guichard <james.n.guichard@futurewei.com>; Tal Mizrahi <tal.mizrahi.phd@gmail.com>; draft-ietf-sfc-ioam-nsh@ietf.org
Objet : Re: [sfc] WGLC for  https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

Hi Med, Greg,
How about this text :
“The O-bit MUST be handled following the rules in and any updates to [RFC8300] ."
Given that I-D.ietf-sfc-oam-packet  will update RF8300 and there could be others in future?
Thanks,
Shwetha

On Tue, Apr 12, 2022 at 9:24 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Shwetha,
I believe that the text you've quoted is helpful. I would suggest changing references from [RFC8300] to [I-D.ietf-sfc-oam-packet] throughout that paragraph.
Regards,
Greg

On Tue, Apr 12, 2022 at 7:56 AM Shwetha Bhandari <shwetha.bhandari@thoughtspot.com> wrote:
Med,
Thanks for the details: this is exactly what we had before the latest revision:
4.2.  IOAM and the use of the NSH O-bit
[RFC8300] defines an "O bit" for OAM packets.  Per [RFC8300] the O
bit must be set for OAM packets and must not be set for non-OAM
packets.  Packets with IOAM data included MUST follow this
definition, i.e. the O bit MUST NOT be set for regular customer
traffic which also carries IOAM data and the O bit MUST be set for
OAM packets which carry only IOAM data without any regular data
payload.
This was removed as per the discussion in this thread. Please check  https://mailarchive.ietf.org/arch/msg/sfc/srMit5zE8UseNOhxknAw_dqvj6M/
It looks like we are going in a loop here. This definition of SFC OAM packet to include the OAM data that comes in inner packets via the next protocol header chain is introduced in draft-ietf-sfc-oam-packet to update the RFC8300.
Jim, What are you thoughts on this? Should we reintroduce the above text ?
Thanks,
Shwetha
_________________________________________________________________________________________________________________________
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.