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

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Mon, 17 Oct 2016 09:15:12 +0000

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, "[email-masked]" <[email-masked]> 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 Allocation Identifier
    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

---

From: Ron Parker <[email-masked]>
Date: Mon, 17 Oct 2016 14:50:40 +0000

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:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE)
Sent: Monday, October 17, 2016 5:15 AM
To: [email-masked]
Subject: [GRAYMAIL] [sfc] FW: New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

G/

------

    

    Abstract:

                                                                                      

    The IETF Secretariat

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Mon, 17 Oct 2016 16:10:17 +0000

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 [[email-masked]] on behalf of Ron Parker [[email-masked]]
Sent: Monday, October 17, 2016 10:50 AM
To: Van De Velde, Gunter (Nokia - BE); [email-masked]
Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

Gunter,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE)
Sent: Monday, October 17, 2016 5:15 AM
To: [email-masked]
Subject: [GRAYMAIL] [sfc] FW: New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

G/

------

    Abstract:

    The IETF Secretariat

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Mon, 17 Oct 2016 16:52:00 +0000

See inline: GV>

On 17/10/2016, 18:10, "Dave Dolson" <[email-masked]> wrote:

GV> There is indeed something to say for that. However, For a NSH Type-1 MD allocation , the length field has no real contributing value, beyond containing the number 0x06. 

GV> And this would be fine also… current issue is that the way NSH MD Type-1 is currently defined it is considered as Opaque content data, and the allocation scheme is part left out from NSH definition… If for each of the allocation schemes a new MD type is allocated, then each SF can identify how to read the MD fields and the meta-data field in stateless universal fashion and life is easy and consistent… however, the current reality is different.

G/

--------------------------------------------------------------------------------

it is progressed currently for the allocation 

    -Dave

    Gunter,

       Ron

    -----Original Message-----
    From: sfc [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE)
    Sent: Monday, October 17, 2016 5:15 AM
    To: [email-masked]
    Subject: [GRAYMAIL] [sfc] FW: New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

    G/
    
    ------

    

        Abstract:

    

        The IETF Secretariat

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 17 Oct 2016 17:07:28 +0000

> On Oct 17, 2016, at 12:10 PM, Dave Dolson <[email-masked]> wrote:
> 
> 

I agree with this. I’d much rather keep the Length to mean just Length for all MD Types.

Thanks,

— Carlos.

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Mon, 17 Oct 2016 18:14:56 +0000

My understanding is that the only reason to not overload length is for consistency … It is easier, but not very useful and neither valuable usage of the field at all.

I do see great value in a stateless mechanism to understand how the metadata is structured… otherwise, why even have a NSH header if we could just stuff all state in the network flowstate? (Openflow and OVSDB could do the job perfectly with a central controller to distribute state)… however, It reduces value of NSH framework and adds operational complexity.

Using the SPI could work, but only if there are few bits reserved for this purpose… That is not the case and hence adds extra state in the network, to make the SF’s understand how the SPI and MD could be interpreted…

Hence the proposal to overload the length field… An alternative is to use for each allocation type a new NSH MD type and add maybe allocation context in the metadata content itself, which was suggested by Dave D.

G/

    
    
    Thanks,
    
    — Carlos.

---

From: Lucy yong <[email-masked]>
Date: Mon, 17 Oct 2016 20:32:10 +0000

Just notice this content of this thread. 

If we want to go this approach, using MD type is better way for it than using the length. This means to specify MD type specific semantics. Not sure if it can address SFC variety, we may need a more bits for MD type.  

The reason to have MD type 1 in NSH is hardware friendly, do we lose it by doing that?
 
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE)
Sent: Monday, October 17, 2016 1:15 PM
To: Carlos Pignataro (cpignata); Dave Dolson
Cc: [email-masked]; Ron Parker
Subject: Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-length-overload-00.txt

G/

    
    
    Thanks,
    
    — Carlos.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Oct 2016 22:10:35 -0400

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

---

From: <[email-masked]>
Date: Tue, 18 Oct 2016 05:37:50 +0000

Hi Lucy, all,

I didn't see yet implementation results that show that MD#1 is HW friendly compared to MD#2.

That said, MD#1 is underspecified as it leaves four fields without any meaning... which opens the door for interoperability issues.

draft-vandevelde-sfc-nsh-length-overload tries to address this problem. We may agree/disagree on the overloading approach but the authors have a point here:
* Given that various documents are associating a meaning with the 4 context headers of MD#1, how to help implementations know which variant to use?

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Lucy yong
> Envoyé : lundi 17 octobre 2016 22:32
> À : Van De Velde, Gunter (Nokia - BE); Carlos Pignataro (cpignata); Dave
> Dolson
> Cc : Ron Parker; [email-masked]
> Objet : Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-
> length-overload-00.txt
> 
> If we want to go this approach, using MD type is better way for it than
> using the length. This means to specify MD type specific semantics. Not
> sure if it can address SFC variety, we may need a more bits for MD type.
> 
> My understanding is that the only reason to not overload length is for
> consistency … It is easier, but not very useful and neither valuable usage
> of the field at all.
> 
> I do see great value in a stateless mechanism to understand how the
> metadata is structured… otherwise, why even have a NSH header if we could
> just stuff all state in the network flowstate? (Openflow and OVSDB could
> do the job perfectly with a central controller to distribute state)…
> however, It reduces value of NSH framework and adds operational
> complexity.
> 
> Using the SPI could work, but only if there are few bits reserved for this
> purpose… That is not the case and hence adds extra state in the network,
> to make the SF’s understand how the SPI and MD could be interpreted…
> 
> Hence the proposal to overload the length field… An alternative is to use
> for each allocation type a new NSH MD type and add maybe allocation
> context in the metadata content itself, which was suggested by Dave D.
> 
> G/
> 
> 
>     > 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
>     >
>     > 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
>     >
>     >
>     > 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/
>     >
>     > ------
>     >
>     >    URL:            https://www.ietf.org/internet-drafts/draft-
> vandevelde-sfc-nsh-length-overload-00.txt

---

From: Lucy yong <[email-masked]>
Date: Tue, 18 Oct 2016 14:27:12 +0000

Hi Med,

I didn't see yet implementation results that show that MD#1 is HW friendly compared to MD#2.
[Lucy]  same here. If we want leave the control plane to define the MD#1 structure and expect that there are many, HW friendly is diminished. 

That said, MD#1 is underspecified as it leaves four fields without any meaning... which opens the door for interoperability issues.
[Lucy] Understand. If Section 3.4 adds text: this section only defines MD type 1 format. The semantics of MD Type 1 is outside the scope of this document. Thus, the use of MD type 1 is outside the scope of this document. -end. This will leave other document to address how to use it and interoperability issue.  

draft-vandevelde-sfc-nsh-length-overload tries to address this problem. We may agree/disagree on the overloading approach but the authors have a point here:
* Given that various documents are associating a meaning with the 4 context headers of MD#1, how to help implementations know which variant to use?
[Lucy] agree with the point. If two SFC applications using different semantics of MD type 1 header run separately, i.e. no sharing any SF, they will not create an interoperability issue. Do we want to address the interoperability issue of MD#1 in this way or we want an SF implementation to be in an environment of multiple semantics of MD#1? 

Thanks,
Lucy 

Thank you.

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Lucy yong Envoyé 
> : lundi 17 octobre 2016 22:32 À : Van De Velde, Gunter (Nokia - BE); 
> Carlos Pignataro (cpignata); Dave Dolson Cc : Ron Parker; [email-masked] 
> Objet : Re: [sfc] New Version Notification for 
> draft-vandevelde-sfc-nsh- length-overload-00.txt
> 
> If we want to go this approach, using MD type is better way for it 
> than using the length. This means to specify MD type specific 
> semantics. Not sure if it can address SFC variety, we may need a more bits for MD type.
> 
> Subject: Re: [sfc] New Version Notification for 
> draft-vandevelde-sfc-nsh- length-overload-00.txt
> 
> consistency … It is easier, but not very useful and neither valuable 
> usage of the field at all.
> 
> metadata is structured… otherwise, why even have a NSH header if we 
> could just stuff all state in the network flowstate? (Openflow and 
> OVSDB could do the job perfectly with a central controller to 
> distribute state)… however, It reduces value of NSH framework and adds 
> operational complexity.
> 
> Using the SPI could work, but only if there are few bits reserved for 
> this purpose… That is not the case and hence adds extra state in the 
> network, to make the SF’s understand how the SPI and MD could be 
> interpreted…
> 
> Hence the proposal to overload the length field… An alternative is to 
> use for each allocation type a new NSH MD type and add maybe 
> allocation context in the metadata content itself, which was suggested by Dave D.
> 
> G/
> 
> 
> On 17/10/2016, 19:07, "Carlos Pignataro (cpignata)" 
> <[email-masked]>
> 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.
> 
>     > Subject: Re: [sfc] New Version Notification for 
> draft-vandevelde- sfc-nsh-length-overload-00.txt
>     >
>     > Gunter,
>     >
>     > 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/
>     >
>     > ------
>     >

---

From: <[email-masked]>
Date: Tue, 18 Oct 2016 14:53:15 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Lucy yong [mailto:[email-masked]]
> Envoyé : mardi 18 octobre 2016 16:27
> À : BOUCADAIR Mohamed IMT/OLN; Van De Velde, Gunter (Nokia - BE); Carlos
> Pignataro (cpignata); Dave Dolson
> Objet : RE: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-
> length-overload-00.txt
> 
> 
> 
> Hi Med,
> 
> [Lucy]  same here. If we want leave the control plane to define the MD#1
> structure and expect that there are many, HW friendly is diminished.
> 

[Med] Agree. FWIW, we already have this text in the control requirement draft: 

   Also, this interface informs the SFC-aware SF about the semantics of
   a context information, which would otherwise have opaque meaning.

> That said, MD#1 is underspecified as it leaves four fields without any
> meaning... which opens the door for interoperability issues.
> [Lucy] Understand. If Section 3.4 adds text: this section only defines MD
> type 1 format. The semantics of MD Type 1 is outside the scope of this
> document. Thus, the use of MD type 1 is outside the scope of this
> document. -end. This will leave other document to address how to use it
> and interoperability issue.
> 

[Med] I agree with Joel here. The proposed NEW text does not solve the interoperability issue. It only acknowledges it. IMHO, we need to say more. 

> draft-vandevelde-sfc-nsh-length-overload tries to address this problem. We
> may agree/disagree on the overloading approach but the authors have a
> point here:
> * Given that various documents are associating a meaning with the 4
> context headers of MD#1, how to help implementations know which variant to
> use?
> [Lucy] agree with the point. If two SFC applications using different
> semantics of MD type 1 header run separately, i.e. no sharing any SF, they
> will not create an interoperability issue. Do we want to address the
> interoperability issue of MD#1 in this way or we want an SF implementation
> to be in an environment of multiple semantics of MD#1?

[Med] Good point. Calling out explicitly those assumptions in the draft is a clear enhancement of the spec. BTW, if all is instructed via the control plane, I don't see why MD#1 would then mandate that the same semantic be applied along a chain/path/domain. I reckon that it is more natural in such case to use MD#2 (which I would like to see as a MANDATORY_TO_IMPLEMENT in the NSH draft, but that's another issue.).

> >     >    has been successfully submitted by Gunter Van de Velde and
> posted
> > to the
> >     >    IETF repository.
> >     >
> >     >    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]
> >     >       consequence, an NSH MD Type 1 header is always Length 0x6
> (six
> > 4-byte
> >     >       This draft proposes to overload the Length field of an NSH
> MD
> > Type 1
> >     >       Length field overload intends to allow universal
> understanding
> > at any
> >     >    Please note that it may take a couple of minutes from the time
> of
> > submission

---

From: [email-masked]
Date: Tue, 25 Oct 2016 10:36:54 +0800

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" <[email-masked]> 写于 2016/10/18 10:10:35:

> "Joel M. Halpern" <[email-masked]> 
> 发件人:  "sfc" <[email-masked]>
> 
> 2016/10/18 10:10
> 
> 收件人
> 
> Dave Dolson <[email-masked]>, Ron Parker 
> <[email-masked]>, "Van De Velde, Gunter (Nokia - 
> BE)" <[email-masked]>, "[email-masked]" <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> Re: [sfc] New Version Notification for draft-vandevelde-sfc-nsh-
> length-overload-00.txt
> 
> >     A new version of I-D, 
draft-vandevelde-sfc-nsh-length-overload-00.txt
> >     Title:              Network Services Header Context 
AllocationIdentifier
> sfc-nsh-length-overload-00
> >
> >
> >     Abstract:
> of submission

---

From: Ron Parker <[email-masked]>
Date: Tue, 25 Oct 2016 13:32:43 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 24, 2016 10:37 PM
To: Joel M. Halpern <[email-masked]>; Van De Velde, Gunter (Nokia - BE) <[email-masked]>
Cc: sfc <[email-masked]>; [email-masked]; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>
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" <[email-masked]<mailto:[email-masked]>> 写于 2016/10/18 10:10:35:

> "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
> 发件人:  "sfc" <[email-masked]<mailto:[email-masked]>>
>
> 2016/10/18 10:10
>
> 收件人
>
> Dave Dolson <[email-masked]<mailto:[email-masked]>>, Ron Parker
> <[email-masked]<mailto:[email-masked]>>, "Van De Velde, Gunter (Nokia -
> BE)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
>
> 抄送
>
> 主题
>
> > To: Van De Velde, Gunter (Nokia - BE); [email-masked]<mailto:[email-masked]>
> > To: [email-masked]<mailto:[email-masked]>
> > On 17/10/2016, 10:05, "[email-masked]<mailto:[email-masked]>" <internet-
> [email-masked]<mailto:[email-masked]>> wrote:
> >
> >
> >     Title:              Network Services Header Context AllocationIdentifier
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Wed, 26 Oct 2016 11:10:49 +0800

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 <[email-masked]> 
2016/10/25 21:32

收件人
"[email-masked]" <[email-masked]>, "Joel M. Halpern" 
<[email-masked]>, "Van De Velde, Gunter (Nokia - BE)" 
<[email-masked]>, 
抄送
sfc <[email-masked]>, "[email-masked]" <[email-masked]>, Dave Dolson 
<[email-masked]>
主题
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:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 24, 2016 10:37 PM
To: Joel M. Halpern <[email-masked]>; Van De Velde, Gunter (Nokia - 
BE) <[email-masked]>
Cc: sfc <[email-masked]>; [email-masked]; Ron Parker 
<[email-masked]>; Dave Dolson <[email-masked]>
Subject: Re: [sfc] New Version Notification for 
draft-vandevelde-sfc-nsh-length-overload-00.txt
 
Dear all, 

BRs, 
Linda Wang 

AllocationIdentifier

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 26 Oct 2016 05:35:49 +0000

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 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, October 25, 2016 at 8:10 PM
To: Ron Parker <[email-masked]>, "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>, Dave Dolson <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, sfc <[email-masked]>, "[email-masked]" <[email-masked]>
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:

   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

2016/10/25 21:32

收件人

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

抄送

sfc <[email-masked]>, "[email-masked]" <[email-masked]>, Dave Dolson <[email-masked]>

主题

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

Linda,

   Ron

Dear all,

BRs,
Linda Wang

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Oct 2016 03:15:24 -0400

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, [email-masked] wrote:
> 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
> 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.
>
> 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
>
>> "Joel M. Halpern" <[email-masked]> 发件人:  "sfc"
>> <[email-masked]>
>>
>> 2016/10/18 10:10
>>
>> 收件人
>>
>> 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
>>
>>> that
>> field that can be used to discriminate metadata allocations.
>> Values 3,4,5,... are available for different MD encodings.
>>>
>>> -Dave
>>>
>>> ________________________________________ From: sfc
>>> [[email-masked]] on behalf of Ron Parker
>> [[email-masked]]
>>> Sent: Monday, October 17, 2016 10:50 AM To: Van De Velde, Gunter
>>> (Nokia - BE); [email-masked] Subject: Re: [sfc] New Version
>>> Notification for draft-vandevelde-
>> sfc-nsh-length-overload-00.txt
>>>
>>> Gunter,
>>>
>> Type 1 which will undoubtedly improve interworking between
>> different implementations and between different administrative
>> domains.
>>>
>>> Ron
>>>
>>>
>>> -----Original Message----- From: sfc
>>> [mailto:[email-masked]] On Behalf Of Van De Velde,
>> Gunter (Nokia - BE)
>>> Sent: Monday, October 17, 2016 5:15 AM To: [email-masked] Subject:
>>> [GRAYMAIL] [sfc] FW: New Version Notification for draft-
>>> as
> posted to the
>>> 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-
>>> Abstract: The specification of the NSH MD Type 1 header
> [draft-ietf-sfc-nsh]
> (six 4-byte
>>> started to do so.  A need to distinguish types of Context
>>> Headers therefore arises.
>>>
> understanding at any
>>> _______________________________________________ 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
>>>
>>
>> _______________________________________________ sfc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc