Re: [RTG-DIR] Rtgdir review of draft-ietf-sfc-ioam-nsh-10

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Mach,

Thanks again - and thanks to Greg for the clarifications on the O-bit. 
We just posted revision -11 of draft-ietf-sfc-ioam-nsh (https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/11/) which includes the following in section 3:
   
  The operator MUST ensure that all nodes along the service path support IOAM.  
  Otherwise packets with IOAM are likely to be dropped per [RFC8300].

Cheers, Frank

> -----Original Message-----
> From: Mach Chen <[e-mail]>
> Sent: Saturday, 24 September 2022 03:55
> To: Frank Brockners (fbrockne) <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: Rtgdir review of draft-ietf-sfc-ioam-nsh-10
> 
> Hi Frank,
> 
> Please my responses inline...
> 
> > -----Original Message-----
> > From: Frank Brockners (fbrockne) <[e-mail]>
> > Sent: Monday, September 12, 2022 4:06 AM
> > To: Mach Chen <[e-mail]>; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: Rtgdir review of draft-ietf-sfc-ioam-nsh-10
> >
> > Hi Mach,
> >
> > Thanks a lot for your detailed review - and sorry for the delay. Please see
> inline.
> >
> > > -----Original Message-----
> > > From: Mach Chen <[e-mail]>
> > > Sent: Saturday, 27 August 2022 11:16
> > > To: [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Rtgdir review of draft-ietf-sfc-ioam-nsh-10
> > >
> > > Hello,
> > > I have been selected as the Routing Directorate reviewer for this
> > > draft. The Routing Directorate seeks to review all routing or
> > > routing-related drafts as they pass through IETF last call and IESG
> > > review, and
> > sometimes on special request.
> > > The purpose of the review is to provide assistance to the Routing ADs.
> > > For more information about the Routing Directorate, please see
> > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> > > Although these comments are primarily for the use of the Routing
> > > ADs, it would be helpful if you could consider them along with any
> > > other IETF Last Call comments that you receive, and strive to
> > > resolve them through discussion or by updating the draft.
> > >
> > > Document: draft-ietf-sfc-ioam-nsh-10
> > > Reviewer: Mach Chen
> > > Review Date: 2022-08-22
> > > IETF LC End Date:
> > > Intended Status: Standards Track
> > >
> > > Summary:
> > > I have some minor concerns about this document that I think should
> > > be resolved before publication.
> > >
> > > Comments:
> > > The draft is well written and easy to read.
> > >
> > > Section 3,
> > > "The O-bit MUST be handled following the rules in [I-D.ietf-sfc-oam-
> packet]."
> > >
> > > According to [I-D.ietf-sfc-oam-packet], a NSH-encapsulated packet
> > > with IOAM will not be considered as OAM packet. Thus, it's better to
> > > state that "the O-bit MUST NOT be set" for packet with IOAM header
> > > in this
> > document.
> >
> > ...FB: I'm not sure that [I-D.ietf-sfc-oam-packet] states that a
> > NSH-encapsulated packet with IOAM will not be considered as OAM
> > packet, at least I did not find a reference. Do you have a pointer?
> > There have been a lot of discussions on the O-bit in NSH including the
> > use with IOAM. After careful consideration, it was decided to refer to
> > [I-D.ietf-sfc-oam-packet] for the handling of the O-bit, rather than
> > re-state things in draft-ietf-sfc-ioam-nsh. The reason for that is,
> > that one needs to consider a variety of cases, including cases, where
> > an operator would decide to add IOAM information to an NSH OAM packet,
> > in which case the O-bit would be set according to draft-ietf-sfc-oam-packet.
> 
> As discussed with Greg, draft-ietf-ippm-ioam-flags defines an Active flag that
> might create Active OAM packet, in that case the "O" bit will be set. And I agree
> with Greg it's better to keep the quoted text as-is. Therefore, please ignore this
> comment.
> 
> >
> > >
> > > Major Issues:
> > > No major issues found.
> > >
> > > Minor Issues:
> > > Quoted from Section 2.2, last paragraph of RFC 8300, it says:
> > > "...Packets with Next Protocol values not supported SHOULD be
> > > silently
> > dropped
> > >       by default, although an implementation MAY provide a configuration
> > >       parameter to forward them."
> > >
> > > With above requirement, when insert an IOAM header to a
> > > NSH-encapsulated packet, the encapsulating node MUST make sure that
> > > every nodes (e.g., SFF, SF) along the service path supports IOAM,
> > > otherwise, the packet will be silently dropped. IMHO, this should be
> > > discussed in the document to make this more explicit.
> >
> > ...FB: Good point. If we follow the approach of RFC8300, wouldn't it
> > make sense to also use SHOULD here? I.e., the operator SHOULD ensure
> > that all nodes along the service path support IOAM. Otherwise packets
> > with IOAM are likely to be dropped per [RFC 8300].
> 
> I fine with using "MUST" or "SHOULD”, and your example text looks good to me.
> 
> >
> > Thanks again, Frank
> 
> You are welcome!
> 
> Best regards,
> Mach
> >
> > >
> > > Nits:
> > > None.
> > >
> > > Best regards,
> > > Mach