Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03

From: <[email-masked]>
Date: Mon, 2 May 2016 11:58:47 +0000

Hi Jim, all,

I interpret this proposal as if it wants to inherit the IPFIX Application information to be conveyed in an nsh header. I have some issues with the rationale of this draft, not its goal per se.

I do not support this draft. I do think there are other design choices that can be investigated by the WG to inherit existing IPFIX IEs without writing a new RFC for it for EACH IE to be conveyed in an NSH header.

For example, there is a more general proposal that aims to import ANY IPFIX Information Element (that will cover the particular case in this document): http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html without consuming the WG effort to edit/review/publish RFCs for each promising IPFIX IEs.

Further, I have the following questions for the draft:

·         Why reserving this proposal for MD#1?

·         What means the following headers?
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       3       |        0      |              161              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Network Shared Context                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Platform Context                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Service Shared Context                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 2: Example of Metadata Including the SNMP Application
                              Identification

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 29 avril 2016 18:31
À : [email-masked]
Objet : [sfc] Call for WG adoption of draft-penno-sfc-appid-03

Dear WG:

We did not receive many responses for this call for adoption and therefore would like to re-invite people to post their thoughts on adopting this document into the SFC WG. The call for adoption will run for a further 2 weeks ending 6/13/2016.

Thanks!

SFC Chairs

From: Jim Guichard <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 11, 2016 at 3:24 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Call for WG adoption of draft-penno-sfc-appid-03

Dear WG:

This email serves as a call for WG adoption of draft-penno-sfc-appid-03 as a WG document. The call for adoption will run for 2 weeks ending 2/25/2016.

Please note that this is a call for adoption, and not a last call for content of the document. Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and use that document for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issues you have with the current document itself can also be raised, but they should be raised in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies to this draft, in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this email (to the chairs) whether or not you are aware of any relevant IPR.

Thanks!

SFC Chairs

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 2 May 2016 13:44:03 +0000

Dear Med,

Since you are making a generic comment outside the scope of draft-penno-sfc-appid-03, I thought it appropriate to extract that comment, and reply to it under separate cover (updating also the Subject line)

> On May 2, 2016, at 7:58 AM, [email-masked] wrote:
> 
> For example, there is a more general proposal that aims to import ANY IPFIX Information Element (that will cover the particular case in this document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html <http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html> without consuming the WG effort to edit/review/publish RFCs for each promising IPFIX IEs.
> 

There have been a number of responses on the list highlighting the significant drawbacks of this proposal. However, although I agree with those, I think I have not yet replied enlist.

Here’s my view.

The IPFIX Information Elements registry contains over 450 entries. It also has data types, semantics, and units associated with them. These are in support of a protocol for transmitting Traffic Flow Information. Looking at the SFC Architecture at RFC 7665, the Metadata is used for a completely different purpose. Yes, there is intersection with some IPFIX fields. But there’s also intersection with the IF-MIB.

First, IPFIX is not a superset of all the information needed. Looking at the WG doc on mobility and DC, and the various allocation drafts, not every fields is in IPFIX.
Second, not every IPFIX field is needed in SFC (certainly not the 450+).

The corollary of this is that there are a number of associated problems with the proposal:
1. Does an SFC implementation need to support all (ever growing) IPFIX IEs?
2. Do you propose to specify profiles of IPFIX, which include a subset to be used? That seems in practice more difficult than the direct alternative.
3. Regarding fields not defined in IPFIX, does SFC need to specify a new IPFIX IE, and specify how it would be used with IPFIX?
4. What about newly defined IPFIX fields after the publishing of the NSH documents? How are those vetted for applicability to SFC?
5. What is SFC needs a different data type for a field?

In my opinion, all of this result in a lot more work and uncertainty than actually defining what’s needed.

I expect some SFC/NSH use cases to use an ifIndex for example. This does not imply that SFC need to import somehow the full IF-MIB.

Similarly, I expect SFC/NSH can use specific fields or values from various places, when it makes sense. I do not expect NSH needing to import all of those.

In summary, I believe this proposal is harmful to NSH on the above technical grounds. As a general proposal, it seems to me like a cannon to kill a fly.

I expect SFC might need to define things like flow specifications, it does not mean it ought to reuse the BGP Flow Spec registries, semantics, and syntax.

That said, as SFC defines things from a flow, I expect it will not re-invent the wheel and re-use surgically.

Best,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 2 May 2016 13:52:35 +0000

Dear Med,

Thanks for taking the time to review and comment. Please find some comments inline.

> I do not support this draft. I do think there are other design choices that can be investigated by the WG to inherit existing IPFIX IEs without writing a new RFC for it for EACH IE to be conveyed i…

I believe you are misunderstanding what draft-penno-sfc-appid-03 is about. The goal is to convey application information in SFC Metadata. It is not to inherit existing IPFIX IEs.

Given this goal of conveying application information, we found one specific syntax leveraging the Application Information structure from IPFIX.

I wanted to clarify the difference, as it is significance.

If there are other design choices *to convey application identification* (not to inherit existing fields from anywhere as a goal), we’d love to hear them.

This specific proposal compiles and runs.

> For example, there is a more general proposal that aims to import ANY IPFIX Information Element (that will cover the particular case in this document):http://www.ietf.org/mail-archive/web/sfc/curre…

I believe this will cause more headaches than solutions — I replied in a separate note.

> ·         Why reserving this proposal for MD#1?

Because that is the minimal one to use. However, this is also defined for MD-Type 2 at https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 (see “5.   Application ID”)

Do you suggest we should define MD-Type 2 in this draft as well? Happy to do so if that’s useful.

> ·         What means the following headers?

It is an example of metadata including the SNMP application identification.

Best,

— Carlos.

> From: Jim Guichard <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Please note that this is a call for adoption, and not a last call for content of the document. Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and use that document for resolving open issues and documenting the WG’s decisions.
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Mon, 2 May 2016 14:24:31 +0000

Hi Carlos,

Please see inline.

Cheers,
Med

De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
Envoyé : lundi 2 mai 2016 15:44
À : BOUCADAIR Mohamed IMT/OLN
Cc : Jim Guichard (jguichar); [email-masked]
Objet : Reuse the IPFIX registry in NSH

Dear Med,

Since you are making a generic comment outside the scope of draft-penno-sfc-appid-03,
[Med] Perhaps I misunderstood the proposal, but Reinaldo’s draft says the following:

   This document purposes the use of IPFIX [RFC7011<https://tools.ietf.org/html/rfc7011>] application
   information to be carried in the NSH context metadata of a MDType-1
   packet.

So, I don’t think it is outside the scope of that discussion. My position is simple: instead of looking at an individual proposal (that may have its merit), what if we consider an approach that does not require the involvement of the WG to reused another IPFIX IE.

I thought it appropriate to extract that comment, and reply to it under separate cover (updating also the Subject line)
[Med] I disagree this is out of scope of that discussion, but I’m open to discuss whatever the title of thread is.

On May 2, 2016, at 7:58 AM, [email-masked]<mailto:[email-masked]> wrote:

For example, there is a more general proposal that aims to import ANY IPFIX Information Element (that will cover the particular case in this document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html without consuming the WG effort to edit/review/publish RFCs for each promising IPFIX IEs.

Here’s my view.

The IPFIX Information Elements registry contains over 450 entries.
[Med] This is an argument that a piece of information that is needed in the context of SFC is likely to be defined in that rich list.

It also has data types, semantics, and units associated with them.
[Med] I don’t see any issue there.

These are in support of a protocol for transmitting Traffic Flow Information.
[Med] I don’t see the link with the proposal on the table. This part is not needed at all!

Looking at the SFC Architecture at RFC 7665, the Metadata is used for a completely different purpose.
[Med] The IPFIX proposal is about identifying a piece of information NOT about how to use it.

Yes, there is intersection with some IPFIX fields. But there’s also intersection with the IF-MIB.
[Med] I won’t comment this part because it tries to mix things.

First, IPFIX is not a superset of all the information needed.
[Med] Agree. I never claimed that!

Looking at the WG doc on mobility and DC, and the various allocation drafts, not every fields is in IPFIX.
[Med] The proposal is not about reusing all the fields in IPFIX, but to reuse the ** IPFIX IEs ** registry.

Second, not every IPFIX field is needed in SFC (certainly not the 450+).
[Med] I never claimed that, too!

The corollary of this is that there are a number of associated problems with the proposal:
1. Does an SFC implementation need to support all (ever growing) IPFIX IEs?
Med:  There is no mandatory-to-support metadata as far as I know. This should be part of an RFP and deployment decision.  The question you raised applies for all TLVs.

2. Do you propose to specify profiles of IPFIX, which include a subset to be used? That seems in practice more difficult than the direct alternative.
[Med] No. I’m reproducing here what I answered in another thread: The proposal is not about reusing the IPFIX format, but IPFIX registry. The TLV format as described in the nsh draft will be used. With the approach I’m proposing here:
•   if you need to include a FlowID, you just need to set the registry ID to 1, and the type to 14.
•   If you need to include a vlandID, you just need to set the registry ID to 1, and the type to 58.
•   ..
This is almost close to what Reinaldo’s draft is doing except the authors use a mandatory field.

[Med] No.

4. What about newly defined IPFIX fields after the publishing of the NSH documents?
[Med] I don’t see any issue there at all! We don’t care about IPFIX FIELDS, but about the information elements and their code points. Here is the proposal I shared on the list, fwiw:

==PROPOSAL====

Base version

        0                   1                   2                   3

      |Class  |            Type               | FLAGS |     Length    |

      //                           Data (Variable)                    //

      The description of the fields is as follows:

      Class:  In order to foster service innovation, this field

         allows to inherit from existing code point registries that are

         likely to be useful in a SFC context.  The following values are

         reserved by this specification:

         0:  See IANA section.

         1:  IPFIX [IPFIX].

      Type:  Indicates the code point of the context element.  If

         "Class" field is non-null, the interpretation of this field MUST

         conform to the one defined for that specific class registry. See IANA section.
===

How are those vetted for applicability to SFC?
[Med] I don’t understand the point here. Can you please explicit your point? Thanks.

5. What is SFC needs a different data type for a field?
[Med] This can be defined in a dedicated TLV document.

In my opinion, all of this result in a lot more work and uncertainty than actually defining what’s needed.
[Med] I’m afraid this is pure speculation. I provided the example of vlanid, flowid. I can provide example about the source IP address, source port, protocol, etc.

I expect some SFC/NSH use cases to use an ifIndex for example. This does not imply that SFC need to import somehow the full IF-MIB.
[Med] I don’t see the parallel here.

Similarly, I expect SFC/NSH can use specific fields or values from various places, when it makes sense.
[Med] This is not part of the proposal!

I do not expect NSH needing to import all of those.

In summary, I believe this proposal is harmful to NSH on the above technical grounds.
[Med] My initial objective is to foster service innovation without waiting long cycles to standardize a single code point.

As a general proposal, it seems to me like a cannon to kill a fly.
[Med] I hope things are more clear now after my responses.

Best,

— Carlos.

---

From: <[email-masked]>
Date: Mon, 2 May 2016 14:32:30 +0000

Re-,

Please see inline.

Cheers,
Med

De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
Envoyé : lundi 2 mai 2016 15:53
À : BOUCADAIR Mohamed IMT/OLN
Cc : Jim Guichard (jguichar); [email-masked]; [email-masked]
Objet : Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03

Dear Med,

Hi Jim, all,

I believe you are misunderstanding what draft-penno-sfc-appid-03 is about. The goal is to convey application information in SFC Metadata. It is not to inherit existing IPFIX IEs.
[Med] You may be right but the document explicitly says:

   This document purposes the use of IPFIX [RFC7011<https://tools.ietf.org/html/rfc7011>] application
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   information to be carried in the NSH context metadata of a MDType-1
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   packet.

Given this goal of conveying application information, we found one specific syntax leveraging the Application Information structure from IPFIX.
[Med] Which makes sense. I fully agree with that.

If there are other design choices *to convey application identification* (not to inherit existing fields from anywhere as a goal), we’d love to hear them.
[Med] Who is asking to “inherit existing fields”?

•         Why reserving this proposal for MD#1?

Because that is the minimal one to use.
[Med] I don’t parse this, sorry.

However, this is also defined for MD-Type 2 at https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 (see “5.   Application ID”)
[Med] I don’t think it is a good idea to have a lot of documents to define the same set of information.

Do you suggest we should define MD-Type 2 in this draft as well? Happy to do so if that’s useful.
[Med] No, I’m not proposing that. I’m trying to understand the technical rationale for that choice.

•         What means the following headers?
      0                   1                   2                   3

It is an example of metadata including the SNMP application identification.
[Med] My question was maybe not clear: what a Network Shared Context? What is a Service Platform Context? What is Service Shared Context?

Best,

— Carlos.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 29 avril 2016 18:31
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] Call for WG adoption of draft-penno-sfc-appid-03

Dear WG:

Thanks!

SFC Chairs

Dear WG:

Thanks!

SFC Chairs
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 2 May 2016 14:34:13 +0000

Dear Med,

> On May 2, 2016, at 10:24 AM, [email-masked] wrote:
> 

If this is your objective, I’d suggest that setting appropriate IANA Policies and ranges (including FCFS, Expert Review in particular, and Specification Required) will achieve it without overcomplicating things.

Best,

— Carlos.

---

From: <[email-masked]>
Date: Mon, 2 May 2016 14:42:14 +0000

Re-,

I’m afraid the “FCFS + Specification Required” does not achieve goal. I’m sure you are aware that “permanent and readily available” is needed for “Specification Required”. The expert review will reject the request if the document is not to be published as an RFC:

      Specification Required - Values and their meanings must be
            documented in a permanent and readily available public
            specification, in sufficient detail so that interoperability
            between independent implementations is possible.  When used,
            Specification Required also implies use of a Designated
            Expert, who will review the public specification and
            evaluate whether it is sufficiently clear to allow
            interoperable implementations.  The intention behind
                                            ^^^^^^^^^^^^^^^^^^^^
            "permanent and readily available" is that a document can
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            reasonably be expected to be findable and retrievable long
            after IANA assignment of the requested value.  Publication
                                                           ^^^^^^^^^
            of an RFC is an ideal means of achieving this requirement,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            but Specification Required is intended to also cover the
            case of a document published outside of the RFC path.  For
            RFC publication, the normal RFC review process is expected
            to provide the necessary review for interoperability, though
            the Designated Expert may be a particularly well-qualified
            person to perform such a review.

I still don’t see the “overcomplicating” thing you are talking about. It is like initiating the registry automatically with values for a rich registry.

Cheers,
Med

De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
Envoyé : lundi 2 mai 2016 16:34
À : BOUCADAIR Mohamed IMT/OLN
Cc : Jim Guichard (jguichar); [email-masked]
Objet : Re: Reuse the IPFIX registry in NSH

Dear Med,

On May 2, 2016, at 10:24 AM, [email-masked]<mailto:[email-masked]> wrote:

Best,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 2 May 2016 14:44:08 +0000

Dear Med,

> [Med] Which makes sense. I fully agree with that.

Apologies in advance for asking again, but, what exactly is your concern with this document (beyond your proposal to use IPFIX IEs for everything)?

Some additional follow-ups for closure inline.

> On May 2, 2016, at 10:32 AM, [email-masked] wrote:
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> De : Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> Cc : Jim Guichard (jguichar); [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On May 2, 2016, at 7:58 AM, [email-masked] <mailto:[email-masked]> wrote:
> 
> Hi Jim, all,
> 
>    This document purposes the use of IPFIX [RFC7011 <https://tools.ietf.org/html/rfc7011>] application

Abstract

   This document proposes to use the structured application information
   in the service function chaining metadata, and specifies a YANG model
   for the configuration of the application registry.

> However, this is also defined for MD-Type 2 at https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7 <https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-01#page-7> (see “5.   Application ID”)

Noted. Thank you.

> [Med] No, I’m not proposing that. I’m trying to understand the technical rationale for that choice.

This doc defines MD-Type 1, and the TLV doc defines MD-Type 2 for a bunch of things.

If you have an editorial or information arrangement proposal, please do share. Happy to accommodate to make things easier to parse.

> ·         What means the following headers?

Ah, thanks for the clarification. These are remainders from earlier versions of draft-ietf-sfc-nsh, which we have to fix. This is a good adoption comment and a good catch.

Best,

— Carlos.

> Best,
> 
> — Carlos.
> 
> 
> Cheers,
> Med
> 
> De : sfc [mailto:[email-masked] <mailto:[email-masked]>] De la part de Jim Guichard (jguichar)
> À : [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 2 May 2016 14:51:43 +0000

Dear Med,

Your response is somehow truncating what I said, which changes the meaning. You are quoting me here as saying:
> I’m afraid the “FCFS + Specification Required” does not achieve goal.

But what I wrote is:
> “(including FCFS, Expert Review in particular, and Specification Required)"

Let me please highlight the “Expert Review in particular” portion. The “in particular” text was meant as an emphasizer. The IPFIX IE registry uses Expert Review, with a group of IPFIX (not SFC necessarily) experts. And yes, Spec Required is useful for interacting with other SDOs.

Please note, I do not want to hog the SFC list; this response summarizes my position well enough.

Best,

— Carlos.

> On May 2, 2016, at 10:42 AM, [email-masked] wrote:
> 
> Re-,
> 
> Cc : Jim Guichard (jguichar); [email-masked] <mailto:[email-masked]>
> On May 2, 2016, at 10:24 AM, [email-masked] <mailto:[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 May 2016 10:56:28 -0400

I rather like the idea of being able to use any IPFIX ID that is useful 
for metadata.
Unfortunately, it doesn't work.

The IPFIX Identifiers are associated with a type, and a fixed length 
encoding.  That will not work directly for  SFC MD-2 carriage.  So we 
would have to define how to carry each thing, and watch out for new data 
types being added which we had not described.

Put simply Med, while I wish the IPFIX IE registry was just a list of 
IDs and description, that is not what it is.  It also has associated 
syntax and semantics (identifier, counter, ...) which make application 
to SFC more complex.

Yours,
Joel

On 5/2/16 10:24 AM, [email-masked] wrote:
> Hi Carlos,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :*Carlos Pignataro (cpignata) [mailto:[email-masked]]
> *Envoyé :* lundi 2 mai 2016 15:44
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* Jim Guichard (jguichar); [email-masked]
> *Objet :* Reuse the IPFIX registry in NSH
>
>
>
> Dear Med,
>
>
>
>    This document purposes the use of IPFIX [RFC7011
> <https://tools.ietf.org/html/rfc7011>] application
>
> So, I don’t think it is outside the scope of that discussion. My
> position is simple: instead of looking at an individual proposal (that
> may have its merit), what if we consider an approach that does not
> require the involvement of the WG to reused another IPFIX IE.
>
>
>
> I thought it appropriate to extract that comment, and reply to it under
> separate cover (updating also the Subject line)
>
> [Med] I disagree this is out of scope of that discussion, but I’m open
> to discuss whatever the title of thread is.
>
>
>
>     On May 2, 2016, at 7:58 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>
>
>
>     For example, there is a more general proposal that aims to import
>     ANY IPFIX Information Element (that will cover the particular case
>     in this
>     document):http://www.ietf.org/mail-archive/web/sfc/current/msg04492.html without
>     consuming the WG effort to edit/review/publish RFCs for each
>     promising IPFIX IEs.
>
>
>
>
>
> There have been a number of responses on the list highlighting the
> significant drawbacks of this proposal. However, although I agree with
> those, I think I have not yet replied enlist.
>
>
>
> Here’s my view.
>
>
>
> [Med] This is an argument that a piece of information that is needed in
> the context of SFC is likely to be defined in that rich list.
>
>
>
> Med:  There is no mandatory-to-support metadata as far as I know. This
> should be part of an RFP and deployment decision.  The question you
> raised applies for all TLVs.
>
>
>
> 2. Do you propose to specify profiles of IPFIX, which include a subset
> to be used? That seems in practice more difficult than the direct
> alternative.
>
> [Med] No. I’m reproducing here what I answered in another thread: The
> proposal is not about reusing the IPFIX format, but IPFIX registry. The
> TLV format as described in the nsh draft will be used. With the approach
> I’m proposing here:
>
> 3. Regarding fields not defined in IPFIX, does SFC need to specify a new
> IPFIX IE, and specify how it would be used with IPFIX?
>
> [Med] No.
>
>
>
> [Med] I don’t see any issue there at all! We don’t care about IPFIX
> FIELDS, but about the information elements and their code points. Here
> is the proposal I shared on the list, fwiw:
>
>
>
> ==PROPOSAL====
>
>
>
> Base version
>
>         0                   1                   2                   3
>
> [Med] I’m afraid this is pure speculation. I provided the example of
> vlanid, flowid. I can provide example about the source IP address,
> source port, protocol, etc.
>
>
>
> I expect some SFC/NSH use cases to use an ifIndex for example. This does
> not imply that SFC need to import somehow the full IF-MIB.
>
> [Med] My initial objective is to foster service innovation without
> waiting long cycles to standardize a single code point.
>
>
>
> I expect SFC might need to define things like flow specifications, it
> does not mean it ought to reuse the BGP Flow Spec registries, semantics,
> and syntax.
>
>
>
> That said, as SFC defines things from a flow, I expect it will not
> re-invent the wheel and re-use surgically.
>
>
>
> Best,
>
>
>
> — Carlos.
>
>
>

---

From: <[email-masked]>
Date: Tue, 3 May 2016 06:17:54 +0000

Carlos,

I already explained why I’m objecting to adopt this document at this stage. In addition to that, I have some concerns that I’m listing below:

·         I don’t think it is a good idea to have a lot of documents to define pieces of information that can be supplied using nsh.

·         None of the WG adopted use case documents call for the appid as a mandatory-to-support information.

·         The appid draft (targeting “Standards Track” status) relies on a ** VENDOR ** IPFIX extension (an information RFC). Is there any reason why that information was not part of the normal IPFIX assignment process?

·         There is an IPR for the appid draft. Before endorsing the draft, it would be appropriate for the WG to understand first the problem to solve, agree it is worth to be solved, and then the WG can see whether there are other solution designs without having another yet SFC document with an IPR on it!

Cheers,
Med

Envoyé : lundi 2 mai 2016 16:44

Dear Med,

On May 2, 2016, at 10:32 AM, [email-masked]<mailto:[email-masked]> wrote:

Re-,

Please see inline.

Cheers,
Med

Cc : Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear Med,

Hi Jim, all,

Abstract

Noted. Thank you.

Best,

— Carlos.

Best,

— Carlos.

Cheers,
Med

Dear WG:

Thanks!

SFC Chairs

Dear WG:

Thanks!

SFC Chairs

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 3 May 2016 12:45:18 +0100

On 02/05/2016 15:56, Joel M. Halpern wrote:
> encoding.

Joel

Maybe I misunderstand you point, but IPFIX has the ability to carry
variable length objects - RFC7011 Section 7

Stewart

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 3 May 2016 14:16:02 +0000

Dear Med,

I am trying to understand your objection.

Do you believe that (1) conveying application information in the service function chaining metadata is not a problem the WG should try to solve, that (2) it is a problem for the WG to solve but this document is not a good basis for it and there are other proposals the WG can use which are better (and why), or that (3) something else?

> I do not support this draft. I do think there are other design choices that can be investigated by the WG to inherit existing IPFIX IEs without writing a new RFC for it for EACH IE to be conveyed i…

And my response to that has been that the goal is not to inherit existing IPFIX IEs, and less so in a sweeping broadmost fashion.

More inline...

> On May 3, 2016, at 2:17 AM, [email-masked] wrote:
> 
> Carlos,
> 

Are you advocating a single uber meta-document for all-things NSH?

> ·         None of the WG adopted use case documents call for the appid as a mandatory-to-support information.

I do not believe anyone is saying this is mandatory-to-support, nor that this document is the result of a requirement from some other document.

> ·         The appid draft (targeting “Standards Track” status) relies on a ** VENDOR ** IPFIX extension (an information RFC).

This draft relies on registered IPFIX IEs. What is exactly the issue with these registrations being performed via an Informational RFC?

>  Is there any reason why that information was not part of the normal IPFIX assignment process?

That’s a historical question for the authors of that RFC.

> ·         There is an IPR for the appid draft. Before endorsing the draft, it would be appropriate for the WG to understand first the problem to solve, agree it is worth to be solved, and then the…

That’s exactly what a call-for-adoption is for.

The question of does the WG-at-large believe this is a worthy problem, and does this document propose a good starting point.

For completeness, this is from IETF 93: https://www.ietf.org/proceedings/93/slides/slides-93-sfc-5.pdf <https://www.ietf.org/proceedings/93/slides/slides-93-sfc-5.pdf>

Best,

— Carlos.

> On May 2, 2016, at 10:32 AM, [email-masked] <mailto:[email-masked]> wrote:
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 3 May 2016 12:59:59 -0400

I read this document.
The problem / task is clearly useful, so I support having the WG adopt a 
document to address it.
The proposed information structure seems a good start, so I support 
adoption of this document.

I think it would be helped by a little bit of text explaining how this 
would appear, with what length, in an MD-2 TLV, and what happens if the 
inner implicit length and the outer explicit length don't match.

What is unclear to me is: what is the purpose of the YANG model?
I have no problem with having separate documents defining additional 
TLVs.  We are clearly going to need them.
But defining a YANG model for each TLV seems really strange.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 May 2016 20:43:42 +0000

Agree with Med.

Linda

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, May 03, 2016 1:18 AM
To: Carlos Pignataro (cpignata)
Cc: [email-masked]; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03

Carlos,

Cheers,
Med

Dear Med,

Re-,

Please see inline.

Cheers,
Med

Dear Med,

Hi Jim, all,

Abstract

Noted. Thank you.

Best,

— Carlos.

Best,

— Carlos.

Cheers,
Med

Dear WG:

Thanks!

SFC Chairs

Dear WG:

Thanks!

SFC Chairs