Subject: Re: [mpls] [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

From: Xuxiaohu <[email-masked]>
Date: Wed, 13 Apr 2016 02:26:56 +0000

Hi Joel,

Please see https://tools.ietf.org/html/rfc4928#page-4. Although it's a BCP RFC, it'd better to obey it, IMO. No?

Best regards,
Xiaohu

> -----Original Message-----
> From: Joel Halpern Direct [mailto:[email-masked]]
> Sent: Wednesday, April 13, 2016 10:09 AM
> To: Xuxiaohu
> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> 
> Is there a standards track RFC that requires this?
> 
> I know it is a good practice.  It may even be a good idea for us as a design point,
> as I do want MPLS to be a usable transport for NSH.
> 
> But as far as I can tell, there is no standards track RFC that requires this.
> 
> Yours,
> Joel
> 
> On 4/12/16 9:53 PM, Xuxiaohu wrote:
> > Joel,
> >
> >> -----Original Message-----
> >> From: Joel M. Halpern [mailto:[email-masked]]
> >> Sent: Wednesday, April 13, 2016 9:45 AM
> >> To: Xuxiaohu; Thomas Narten; [email-masked]
> >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> >>
> >> Xu,
> >>        I do not believe that there is an MPLS specification that
> >> requires that all content other than IP must have a first nibble of 0 or 1.
> >
> > When encapsulating NSH over MPLS directly, the first nibble of the NSH must
> not be 4 or 6.
> >
> >> There are specifications where it is discussed as desirable.
> >>
> >> It is in fact pretty trivial for us to change the format so that the
> >> first three bits are 0, but it burns several valuable flag bits.  It
> >> is an SFC working group decision,
> >
> > That's the reason why I raised the first nibble question.
> >
> > Best regards,
> > Xiaohu
> >
> >> not, as far as I can tell, a violation of the MPLS specification.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 4/12/16 9:41 PM, Xuxiaohu wrote:
> >>> Hi Thomas,
> >>>
> >>> It said in the NSH draft:
> >>>
> >>>     "6.  Transport Agnostic: NSH is transport independent and is carried
> >>>          in an overlay, over existing underlays.  If an existing overlay
> >>>          topology provides the required service path connectivity, that
> >>>          existing overlay may be used."
> >>>
> >>> That means the NSH should be able to be transported over MPLS.
> >>> However,
> >> according to the current NSH format definition, it's not safe to
> >> carry the NSH over MPLS due to the first nibble issue. Therefore, I
> >> believe this issue needs to be addressed before publication.
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>>> -----Original Message-----
> >>>> From: sfc [mailto:[email-masked]] On Behalf Of Thomas Narten
> >>>> Sent: Thursday, March 31, 2016 10:48 AM
> >>>> To: [email-masked]
> >>>> Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> >>>>
> >>>> Dear WG:
> >>>>
> >>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt
> >>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/).
> >>>>
> >>>> The editors of the NSH document have indicated that they have
> >>>> addressed all known comments and that there are no open issues with
> >>>> the current version of the document.
> >>>>
> >>>> Substantive comments to the list please, editorial comments can go
> >>>> directly to the document editors.
> >>>>
> >>>> We'll also get a brief update from the editors at next week's
> >>>> meeting. If there are any remaining issues with the document,
> >>>> raising them before the meeting would be especially helpful.
> >>>>
> >>>> For the chairs,
> >>>> Thomas
> >>>>
> >>>> _______________________________________________
> >>>> sfc mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/sfc
> >>>
> >>> _______________________________________________
> >>> sfc mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sfc
> >>>
> >
> > _______________________________________________
> > sfc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc
> >