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

My personal take is that 2 bits for context identification simply will 
not cut it.  We already have 3 (or is it four) context definitions.  And 
while they each name a usage, I do not think that the DC allocation or 
the mobile allocation cover all the arrangements people who are trying 
to use MD-1 will find they need.

Which is why I prefer to leave this to the control plane, as we have 
agreed.  And also why I prefer to have the various allocation drafts as 
informational.

It may be that for control plane purposes we will need an extensible 
registry of allocations.  Or maybe we will not need it.  that can be 
worked out when control plane behaviors are worked out.  (And those may 
be spread across more than one protocol, since "control" for our 
purposes may include traditional control, orchestration, or management 
components.)

Yours,
Joel

On 10/24/16 10:36 PM, wang.cui1@zte.com.cn wrote:
> 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" <sfc-bounces@ietf.org> 写于 2016/10/18 10:10:35:
>
>> "Joel M. Halpern" <jmh@joelhalpern.com> 发件人:  "sfc"
>> <sfc-bounces@ietf.org>
>>
>> 2016/10/18 10:10
>>
>> 收件人
>>
>> Dave Dolson <ddolson@sandvine.com>, Ron Parker
>> <Ron_Parker@affirmednetworks.com>, "Van De Velde, Gunter (Nokia -
>> BE)" <gunter.van_de_velde@nokia.com>, "sfc@ietf.org"
>> <sfc@ietf.org>,
>>
>> 抄送
>>
>> 主题
>>
>> 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
>>> [sfc-bounces@ietf.org] on behalf of Ron Parker
>> [Ron_Parker@affirmednetworks.com]
>>> Sent: Monday, October 17, 2016 10:50 AM To: Van De Velde, Gunter
>>> (Nokia - BE); sfc@ietf.org 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:sfc-bounces@ietf.org] On Behalf Of Van De Velde,
>> Gunter (Nokia - BE)
>>> Sent: Monday, October 17, 2016 5:15 AM To: sfc@ietf.org 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, "internet-drafts@ietf.org" <internet-
>> drafts@ietf.org> 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
>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _______________________________________________ sfc mailing list
>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _______________________________________________ sfc mailing list
>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
>>>
>>
>> _______________________________________________ sfc mailing list
>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc