Re: [sfc] metadata type 1 constraint

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thanks for the clarification, Gunter!

— Carlos

On Oct 26, 2016, at 3:23 AM, Van De Velde, Gunter (Nokia - BE) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Carlos,

Appreciate your perspective.
Interoperability is achieved by creating implementations based upon standard documents, and not based upon informational documents.

There are some aspects in the existing NSH document I agree with:

MD#1:
Fixed length and will carry 16-octets of Opaque Data
As result: The SFC WG should not attempt to define the Opaque structure, as that would make it not Opaque anymore.
It sounds confusing and even a bit schizophrenic from IETF to do such a thing

MD#2:
Has Variable length, carries TLVs and includes standardized context allocation identification.
The existing 16-octet “informational” allocation schemes for Broadband, Mobile and DC fit in here perfectly and the context allocation is carried within the NSH.
Going down the path of defining allocation scheme for broadband, mobile and DC would potentially upgrade these currently “informational” docs to proposed standards, doing better justice to the value these documents.

Conclusion:
For interoperability, should we not aim for allocation schemes based upon full standards instead of ‘informational’ documents?
And defining structure for something that is equally defined as being opaque is asking for misunderstanding and confusion.

G/


From: sfc <[e-mail]<mailto:[e-mail]>> on behalf of "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 25 October 2016 at 16:37
To: "Van De Velde, Gunter (Nokia - BE)" <[e-mail]<mailto:[e-mail]>>
Cc: "Paul Quinn (paulq)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Lucy yong <[e-mail]<mailto:[e-mail]>>
Subject: Re: [sfc] metadata type 1 constraint

Gunter,

There's clearly a trade off and a set of pros and cons for having a header being self-describing versus non-self-describing. Similarly, there's a balance in where we place state.

However, you are making some bold statements below, and I'd like to understand some more. I'm not pushing a position, I just seem to be missing something from your argument.

Saying that a non-self-describing packet / non stateless SF hurts interoperability to the point of uselessness, is attaching that description to MPLS Labels or L2TPv3 encapsulation. Those don't have explicit indications.

You are advocating for an indication of allocation type in the packet. That's not unreasonable in itself, it is a sensible question.

But that is not "stateless" as you call it, because the SF still holds state indexed by SPI, and in any case would need to hold state on what each allocation type means, which implicitly happens without an allocation type. Both need state, both need a control plane to work.

In other words, it seems to me that both (with or without an allocation type) have the *exact* same interoperability requirements and characteristics. The details are different of course, but below seems like FUD.

So, without pushing for any particular method, I'd really would like to understand your technical rational in more details.

You say "marginally useable when interoperability", "dubious usefulness and adds significant operational complexity", and "a formally standardized allocation scheme". The latter should exist in both cases (whether you put it in the packet or not). And while I understand your preference of an explicit allocation type, I still do not understand why.

How exactly the current approach with interoperable running code hurts interoperability?

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 25, 2016, at 00:55, Van De Velde, Gunter (Nokia - BE) <[e-mail]<mailto:[e-mail]>> wrote:
I agree with Lucy and Dave regarding the futile usefulness of MD#1.

The value of a fixed and predictable MD size is clear, however the lack of signalling to indicate in stateless manner the used NSH MD#1 allocation scheme makes this type of NSH header only marginally useable when interoperability of Service function behaviour is required or when a single SF needs to service packets of different NSH MD#1 allocation scheme’s.

The text proposed for adding to MD#1 is not fixing this, however it is making it more clear to the user that MD#1 is from interoperability perspective rather dubious and adds significant operational complexity.

If the intent is to make MD#1 more valuable and if we desire to bank upon the benefits of a fixed size 16 octets context field, then maybe a compromise needs to be made, and some effort be explored to add into the NSH MD#1 a context allocation scheme indication? Or, we create MD#3, MD#4, etc each having a fixed 16-octet size and a formally documented and standardized allocation scheme.

G/

From: sfc <[e-mail]<mailto:[e-mail]>> on behalf of Lucy yong <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 25 October 2016 at 03:04
To: "Paul Quinn (paulq)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [sfc] metadata type 1 constraint

Paul,

If NSH has to support MD-1 with 16-bytes datablock,  please consider adding the additional text we proposed, which addresses interworking concern.

I think that for the MD-2, it also needs to add some rules about when a SFC-aware SF is configured to use metadata and receives MD-2, if it does not understand the MD class and/or type, it MUST NOT process the packet, et al.

Lucy




From: Paul Quinn (paulq) [mailto:[e-mail]]
Sent: Monday, October 24, 2016 4:23 PM
To: Lucy yong
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] metadata type 1 constraint

Hi Lucy,

The value of a fixed size header as a MUST is significant from many perspectives, including but not limited to:

Implementations, including software implementations, benefit form the predictability of a fixed size header. One only needs to look at the lack of widely deployed variable length data plane protocols to see this in practice.

From an operational perspective, having a bounded (small) number of metadata to work with helps to bound the policy expression, which after all is the main use of the metadata.

There are existing implementations that demonstrate the applicability of MD Type 1 to a wide-range of use cases, and those implementation reap the benefits of the two aforementioned points.

Paul

On Oct 21, 2016, at 6:48 PM, Lucy yong <[e-mail]<mailto:[e-mail]>> wrote:

If we intend to standardize metadata structure per an SFC application, I wonder why NSH needs MD#1? MD#2 can support all SFC needs. MD#2 even support expert review metadata class, experimental metadata class as well. Should consider removing MD#1?

Lucy

From: sfc [mailto:[e-mail]] On Behalf Of Vigoureux, Martin (Nokia - FR)
Sent: Friday, October 21, 2016 7:56 AM
To: Van De Velde, Gunter (Nokia - BE); Paul Quinn (paulq); Joel M. Halpern
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [sfc] metadata type 1 constraint

From the latest discussion I wonder if the allocation drafts shouldn't in fact define their own MD type (3, 4, ...).

If there is a need/use for that, a TLV for framing these MDs in MD2 could be defined, as sfc-nsh-tlv now does.

I'd in any case prefer to avoid duplicating specifications across documents, and as such sfc-nsh-tlv should only reference the encodings, not replicate them.

-m


-------- Message d'origine --------
De : "Van De Velde, Gunter (Nokia - BE)" <[e-mail]<mailto:[e-mail]>>
Date :21/10/2016 14:36 (GMT+01:00)
À : "Paul Quinn (paulq)" <[e-mail]<mailto:[e-mail]>>, "Joel M. Halpern" <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [sfc] metadata type 1 constraint
The good news is that draft draft-quinn-sfc-nsh-tlv-02.txt now has a fix suggesting context allocation scheme encoding:

https://tools.ietf.org/rfcdiff?
  url1=https://tools.ietf.org/id/draft-quinn-sfc-nsh-tlv-01.txt
  &url2=https://tools.ietf.org/id/draft-quinn-sfc-nsh-tlv-02.txt

However, if the intent is that MD#1 is Opaque, then why even try to suggest encodings for it? Opaque info is opaque info… either you define it, or you do not define it… anything else is confusing and contradicting from operational and implementation perspective.

I would prefer to see that both “Data Center Allocation” and “Mobility/Broadband Allocation” drafts are written with intended main usage in a MD#2, instead of MD#1 as then it is a complete and interoperable allocation scheme usage with significantly reduced operational overhead and restrictions. Assuming the length of these allocation blobs fixed at 16 octets for potentially stuffing them in a MD#1 sounds fine.

G/



On 19/10/2016, 17:22, "sfc on behalf of Van De Velde, Gunter (Nokia - BE)" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> wrote:

    It is sad that we significantly increase the operational burden for allocation scheme signalling for MD#1. I am dazzled the WG believes stateful signalling is easier for deployment compared with a stateless solution for MD#1. The imposed operational complexity is significant with current proposal.

    G/




    On 19/10/2016, 15:33, "sfc on behalf of Paul Quinn (paulq)" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> wrote:

        Joel,

        I agree with you: the current approach is simple and workable.  The allocation scheme are simply information examples.

        Paul

        > On Oct 18, 2016, at 8:14 PM, Joel M. Halpern <[e-mail]<mailto:[e-mail]>> wrote:
        >
        > Our current approach is to allow definition of allocation schemes, but not to mandate any specific allocation scheme for MD-1.
        > That seems to me to be a good approach, workable, and what we have agreed and documented.
        >
        > Yours,
        > Joel
        >
        > On 10/18/16 12:09 PM, Van De Velde, Gunter (Nokia - BE) wrote:
        >> If NSH MD Type-1 defines for the metadata to be Opaque, then we should not make an effort to define it, and just tread it as Opaque content imo and live with the consequences…and in that case use MD Type-2 for these types of well known metadata transport mechanisms.
        >>
        >> If however, we decide to define the allocation schemes, then we should also architect an indicator for the used allocation scheme.
        >> At this point in time, there models were suggested (overload Length, overload MD type, use few bits of MD context data).
        >> I strongly believe there is value in having the metadata allocation structure signalled within the NSH itself, even for MD Type-1.
        >> (It avoids control plane signalling and creates state which needs to be maintained, and that sounds as a very expensive operation).
        >>
        >> Alternate is to just say as Lucy suggests, and restrict MD Type-1 Service Chain SF’s per allocation scheme. This is a solution that works, albeit it is a very impacting restriction for flexibility and resource sharing).
        >>
        >> G/
        >>
        >>
        >> On 18/10/2016, 16:49, "sfc on behalf of Lucy yong" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> wrote:
        >>
        >>    Comment on "Allocating a nibble or byte within the 32 bytes (probably the first nibble or byte) is yet another."
        >>
        >>    Lucy: Technically We can do this on MD#1, but NSH already defines MD#2. Is the variable length the only feature that hardware can't deal with?
        >>
        >>    Lucy
        >>
        >>    -----Original Message-----
        >>    From: Ron Parker [mailto:[e-mail]]
        >>    Sent: Tuesday, October 18, 2016 10:05 AM
        >>    To: Lucy yong; Joel M. Halpern; [e-mail]<mailto:[e-mail]>
        >>    Subject: RE: [sfc] metadata type 1 constraint
        >>
        >>    Even though the interpretation of metadata is dependent on control plane interaction, where I think the original proposal has value is that there might be multiple separate interpretations simultaneously within the same administrative domain.   A way to describe, on the wire, which of those interpretations is in force for that particular SFP seems valuable to me.   You could definitely argue that the control plane could install the interpretation locally on a per SFP basis;  also being explicit on the wire will likely enhance interoperability and debuggability.
        >>
        >>    The value would be locally significant within the administrative domain (i.e., metadata schema 1, metatadata schema 2, etc.).   Overloading length is one way.   Overloading MD-type is another.   Allocating a nibble or byte within the 32 bytes (probably the first nibble or byte) is yet another.
        >>
        >>       Ron
        >>
        >>
        >>    -----Original Message-----
        >>    From: sfc [mailto:[e-mail]] On Behalf Of Lucy yong
        >>    Sent: Tuesday, October 18, 2016 10:27 AM
        >>    To: Joel M. Halpern <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
        >>    Subject: Re: [sfc] metadata type 1 constraint
        >>
        >>    Joel,
        >>
        >>    Lucy, while your two text proposals are not wrong, I do not see them as adding any clarity to the document.  The sections are very short and clearly define only the syntax.
        >>    [Lucy] True. However, for this document, readers expect Section 3 to describe NSH syntax and semantics. Section 3.1-3.3 do both. If section 3.4 and 3.5 just specify the syntax, from documenting perspective, it is important to explicitly state the two text out.
        >>
        >>    With regard to SF and MD-1 support, there is absolutely nothing that requires an SF to support only one MD-1 structure.  Rather, the control mechanisms will tell the SF how to extract the data it needs from the MD-1 header.
        >>    [Lucy] This puts much uncertainty for a single SF on what to implement, which causes people's concern. IMO, if we don't have a way to address this challenge here (you stated in interim meeting), pushing it to another place does not solve/address it. For example,  will the control mechanisms tell an SF how to extract the data it needs from the MD-1 header per a SFP, or per a SFC, or for all SFC packets, or per payload flow, or combination of them? This will significantly impact SF implementation. The reason having MD type 1 is that is hardware friendly. Leaving these uncertainty open, not sure if the reason still makes a sense.
        >>
        >>    Lucy
        >>    I believe there is already text in the control plane requirements document that describes the need for this control functionality.
        >>
        >>
        >>
        >>    Yours,
        >>    Joel
        >>
        >>    On 10/17/16 11:07 AM, Lucy yong wrote:
        >>    > Suggestions:
        >>    >
        >>    > Section 3.4 should mention that 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.
        >>    >
        >>    > Section 3.5 should mention that this section only defines MEF type 2
        >>    > format. The semantics of MD type 2 is outside the scope of this
        >>    > document. Thus, the use of MD type 2 is outside the scope of this
        >>    > documents.
        >>    >
        >>    > IMO: these statements are important for the sections.
        >>    >
        >>    > Joel, MD semantics is critical for SFs. More than one semantics of MD
        >>    > type 1 MUST NOT be specified for a SF. This should be a requirement in
        >>    > the SFC arch. as a result of NSH design's, but the architecture is
        >>    > already published. Maybe control plane requirement is the place to
        >>    > state this out as the result of SFC arch and NSH design.
        >>    >
        >>    > Thanks, Lucy
        >>    >
        >>    > -----Original Message----- From: sfc [mailto:[e-mail]] On
        >>    > Behalf Of Joel M. Halpern Sent: Sunday, October 16, 2016 8:39 PM To:
        >>    > Lucy yong; [e-mail]<mailto:[e-mail]> Subject: Re: [sfc] metadata type 1 constraint
        >>    >
        >>    > A) I woud not want to state any such constraint in the NSH document,
        >>    > because B) In fact, the SFP ID is in every NSH header.  So yes, there
        >>    > is context if it is needed
        >>    >
        >>    > It is true that MD-2 is more flexible than MD-1.  I don't think anyone
        >>    > disagrees with that.
        >>    >
        >>    > Yours, Joel
        >>    >
        >>    > On 10/16/16 3:25 PM, Lucy yong wrote:
        >>    >> RFC7665 (SFC architecture) states  "This architecture allows an SF to
        >>    >> be part of multiple SFPs and SFCs."
        >>    >>
        >>    >>
        >>    >>
        >>    >> NSH just specifies MD type1 with a 16 bytes field, and  NSH doc.
        >>    >> states
        >>    >>
        >>    >> 3.  NSH provides a mechanism to carry shared metadata between
        >>    >>
        >>    >> participating entities and service functions.  The semantics of
        >>    >>
        >>    >> the shared metadata is communicated via a control plane, which is
        >>    >>
        >>    >> outside the scope of this document, to participating nodes.
        >>    >>
        >>    >>
        >>    >>
        >>    >> Comments: this mean: when an SF that is part of multiple SFCs and MD
        >>    >> type 1 is used in some of SFCs, these SFCs MUST have the same
        >>    >> metadata semantics.  This is because that NSH does not convey SFC
        >>    >> identifier. For MD type 2, different SFCs may insert different list
        >>    >> of TLVs and each TLV has a type and specified semantics along (the
        >>    >> TLVs will be specified in different doc.).
        >>    >>
        >>    >>
        >>    >>
        >>    >> Should we state out this constraint in NSH doc.
        >>    >>
        >>    >>
        >>    >>
        >>    >> Lucy
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >>
        >>    >> _______________________________________________ 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
        >>
        >>
        >
        > _______________________________________________
        > 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

_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc