Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

[Sumandra Majee <[e-mail]>]

There were few other proposals,

a)       The metadata scheme is fixed per path and controller assigns a fixed schema. I think Carlos suggested this. Advantage, no extra bits, disadvantage is that if there are scenarios where a) service path may carry multiple types of context b)  a proxy alters the context

b)       I was suggesting to use the beginning 3 bits of context hdr, but that is yet another form of bit begging, stuffing from all other method.

How about carrying an optional schemaID as part of SPI itself, the SPI is bit rich and folks have been using it for all kinds of stuff anyway.

From: sfc <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Tuesday, October 25, 2016 at 8:10 PM
To: Ron Parker <[e-mail]>, "Van De Velde, Gunter (Nokia - BE)" <[e-mail]>, Dave Dolson <[e-mail]>
Cc: "Joel M. Halpern" <[e-mail]>, sfc <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

Dear Ron,

   Unitl now, there proposed 3 use cases for SFC, including Data center, Mobility and Broadband use case. Different use case use different metadata allocation.
If there is no other use case, 2 bits may be enough to distinguish 3 use cases. Otherwise, 2 bits would be not adequate.

   After long discussion about the NSH draft, I think it may be much more difficult to grow the fixed 16 bytes, but it also proposes a new approach to admit this issue.
Unitl now, 5 approaches have been proposed:

   1. from Ron: grow the fixed 16 bytes
   2. from Gunter:  overload NSH length field
   3. from Dave:  using MD type field, such as value 3,4,5..
   4. from Med:  reckon to use MD Type=2
   5. from Linda: let original MD Type field make 2 bits room for this purpose

   If it is possible, maybe someone can request a slot to discussion this issue during the upcoming meeting to achieve a consensus?

BRs,
Linda Wang



Ron Parker <[e-mail]>

2016/10/25 21:32

收件人

"[e-mail]" <[e-mail]>, "Joel M. Halpern" <[e-mail]>, "Van De Velde, Gunter (Nokia - BE)" <[e-mail]>,

抄送

sfc <[e-mail]>, "[e-mail]" <[e-mail]>, Dave Dolson <[e-mail]>

主题

RE: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt







Linda,

If we do, indeed, set the MD-1 encoding schema ID into the NSH, itself, it doesn’t seem like 2 bits would be adequate.

Perhaps the fixed 16 bytes should grow to include a prepend byte(s) that identifies the encoding schema.

   Ron


From: sfc [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Monday, October 24, 2016 10:37 PM
To: Joel M. Halpern <[e-mail]>; Van De Velde, Gunter (Nokia - BE) <[e-mail]>
Cc: sfc <[e-mail]>; [e-mail]; Ron Parker <[e-mail]>; Dave Dolson <[e-mail]>
Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

Dear all,

  In fact, there is also another solution to address this problem proposed in a previous draft https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-02.
It also proposed to add some bits in NSH, such as reserving 2 bits in the MD-Type field, to identify the exact meaning of the Mandatory Context Headers.
This solution don't bother the length field as well as the MD-type=1/2. But is requires the original MD Type field to make 2 bits room for this purpose.

  On the other hand, I do agree that, both draft-wang-sfc-md-type-issues-02 and draft-vandevelds-sfc-nsh-overload try to propose the issue, we may agree/disagree
on the different approaches, but there should find a agreeable solution for how to understand the exact meaning in the Mandatory Context Headers fields in mixed scenarios.

BRs,
Linda Wang

"sfc" <[e-mail]<mailto:[e-mail]>> 写于 2016/10/18 10:10:35:

> "Joel M. Halpern" <[e-mail]<mailto:[e-mail]>>
> 发件人:  "sfc" <[e-mail]<mailto:[e-mail]>>
>
> 2016/10/18 10:10
>
> 收件人
>
> Dave Dolson <[e-mail]<mailto:[e-mail]>>, Ron Parker
> <[e-mail]<mailto:[e-mail]>>, "Van De Velde, Gunter (Nokia -
> BE)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>,
>
> 抄送
>
> 主题
>
> Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-
> length-overload-00.txt
>
> I agree with Dave.  The length field should always mean length.
> One of the strong benefits of this is that if there is a need (for
> logging, analysis, ...) to get to the data packet but not to understand
> the metadata, the length field always just works.  This significantly
> simplifies many code paths.
>
> Yours,
> Joel
>
> On 10/17/16 12:10 PM, Dave Dolson wrote:
> >
> > I would prefer to see the length field always mean length, so that
> implementations not requiring metadata can just skip the metadata
> regardless of MD type.
> >
> > At the risk of stating the obvious, there already is an MD type
> field that can be used to discriminate metadata allocations. Values
> 3,4,5,... are available for different MD encodings.
> >
> > -Dave
> >
> > ________________________________________
> > From: sfc [[e-mail]] on behalf of Ron Parker
> [[e-mail]]
> > Sent: Monday, October 17, 2016 10:50 AM
> > To: Van De Velde, Gunter (Nokia - BE); [e-mail]<mailto:[e-mail]>
> > Subject: Re: [sfc] New Version Notification for draft-vandevelde-
> sfc-nsh-length-overload-00.txt
> >
> > Gunter,
> >
> > I strongly support this proposal.   It brings more specificity to
> Type 1 which will undoubtedly improve interworking between different
> implementations and between different administrative domains.
> >
> >    Ron
> >
> >
> > -----Original Message-----
> > From: sfc [mailto:[e-mail]] On Behalf Of Van De Velde,
> Gunter (Nokia - BE)
> > Sent: Monday, October 17, 2016 5:15 AM
> > To: [e-mail]<mailto:[e-mail]>
> > Subject: [GRAYMAIL] [sfc] FW: New Version Notification for draft-
> vandevelde-sfc-nsh-length-overload-00.txt
> >
> > Short text about overloading NSH length field for NSH MD Type-1 as
> context allocation type, including proposal for backward compatibility.
> >
> > G/
> >
> > ------
> >
> > On 17/10/2016, 10:05, "[e-mail]<mailto:[e-mail]>" <internet-
> [e-mail]<mailto:[e-mail]>> wrote:
> >
> >
> >     A new version of I-D, draft-vandevelde-sfc-nsh-length-overload-00.txt
> >     has been successfully submitted by Gunter Van de Velde and posted to the
> >     IETF repository.
> >
> >     Name:               draft-vandevelde-sfc-nsh-length-overload
> >     Revision:   00
> >     Title:              Network Services Header Context AllocationIdentifier
> >     Document date:      2016-10-17
> >     Group:              Individual Submission
> >     Pages:              5
> >     URL:            https://www.ietf.org/internet-drafts/draft-
> vandevelde-sfc-nsh-length-overload-00.txt
> >     Status:         https://datatracker.ietf.org/doc/draft-
> vandevelde-sfc-nsh-length-overload/
> >     Htmlized:       https://tools.ietf.org/html/draft-vandevelde-
> sfc-nsh-length-overload-00
> >
> >
> >     Abstract:
> >        The specification of the NSH MD Type 1 header [draft-ietf-sfc-nsh]
> >        mandates four Context Headers, 4-byte each, and they MUST be added
> >        immediately following the Service Path Header.  As direct
> >        consequence, an NSH MD Type 1 header is always Length 0x6 (six 4-byte
> >        words).  As a result, the Length field of the NSH MD Type 1 header
> >        provides an information which is known by simply looking at the "MD
> >        Type" field.  However, while [draft-ietf-sfc-nsh] does not specify
> >        the encoding of these Context Headers, other specifications have
> >        started to do so.  A need to distinguish types of Context Headers
> >        therefore arises.
> >
> >        This draft proposes to overload the Length field of an NSH MD Type 1
> >        as Meta-Data context allocation identifier and to create a IANA
> >        repository for NSH MD Type 1 allocation schemes.  The NSH MD Type 1
> >        Length field overload intends to allow universal understanding at any
> >        network location and by any network device of the context allocation
> >        structure.
> >
> >
> >
> >
> >
> >     Please note that it may take a couple of minutes from the time
> of submission
> >     until the htmlized version and diff are available at tools.ietf.org.
> >
> >     The IETF Secretariat
> >
> >
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/sfc
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/sfc
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/sfc
> >
>
> _______________________________________________
> sfc mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sfc