Subject: [sfc] MD Class registry

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Feb 2017 20:59:26 -0500

In the interim meeting, there was a discussion of clarifying the MD 
Class Registry.  Two changes were proposed.  This email is to solicit 
comments from the WG on those two changes.

First, the MD Class Allocation table.  It currently reserves 0 - 0x01ff 
for IETF review.

The proposal is to reserve 0x0000 for our work, and to reserve the 
remainder of that range (0x0001 - 0x01ff) for IEtF review.

Second, the proposal is to establish the registry for type codes within 
MD Class 0x0000 in the NSH document.  With a policy of RFC Required.  No 
values would be established in the registry by this document, that being 
left ot other documents.

Does anyone see problems with this proposal?
Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 19 Feb 2017 21:09:05 -0500

A related topic on the MD Class and MD Type Registry is that of Vendor 
extensibility.  The current registry text reads:

    0x0000 to 0x01ff: IETF Review
    0x0200 to 0xfff5: Expert Review
    0xfff6 to 0xfffe: Experimental
    0xffff: Reserved

Even with the minor change I raised for discussion in my previous note, 
the only space for Vendor's to define their own type values is in the 
experimental space.  It seems to me that is not sufficient.

How do we want to address this?  We could take a portion of the Class 
space for vendors.  But how would we assign values to vendors for their use?

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Feb 2017 10:12:58 -0000

It seems to me, that we need to sort ourselves out a bit wrt flexibility in
metadata.

We have a hierarchy:
MD Class (2^16)
   MD Type (2^7, about to become 2^8)
      MD TLVs (different docs)

AFAICS only one "optional variable length metadata" can be present in an NSH. 

So I have some observations...

o 2^16 is a lot of MD classes. Really a lot!
o 2^8 is more than plenty MD types in any class
o A vendor-specific MD class only works on an SFP
    made up *entirely* of products from that vendor
o A vendor-specific MD type only works on an SFP
    made up *entirely* of products from that vendor
o The main (only) place we should care about vendor-
    specific pieces of metadata is in the definitions of
    TLVs in MC0/MD2 (not this doc).

Am I missing a particular use case?

Cheers,
Adrian

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 20 February 2017 02:09
> To: [email-masked]
> Subject: Re: [sfc] MD Class registry - Vendor Extensibility
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Mon, 20 Feb 2017 12:10:57 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : lundi 20 février 2017 11:13
> À : 'Joel M. Halpern'; [email-masked]
> Objet : Re: [sfc] MD Class registry - Vendor Extensibility
> 

[Med] Agree.

> o 2^8 is more than plenty MD types in any class

[Med] At least for the mobile case where the practice to "enrich" packets with some data on-path (https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-07#section-3.3) is the rule, the type of data that can be inserted may be very "rich"; see for example Section 7.1 of http://www.etsi.org/deliver/etsi_ts/129200_129299/129230/12.06.00_60/ts_129230v120600p.pdf. 

I know that is frightening but the experience from existing IETF protocols is that a 2^8 type registry can be exhausted: see for the example the RADIUS case http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-2.

In order to cover existing use cases while avoiding coming back to the IETF to claim the type resources have been exhausted, I do suggest to use more bits for the type field. 16 bits would be great.

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 20 Feb 2017 08:52:23 -0500

I am not sure what the line in your note
     "AFAICS only one "optional variable length metadata" can be present 
in an NSH."
means?

In an NSH packet using MD2, there are a sequence of metadata elements. 
Each metdata element has an MD-Class, MD-Type, length, and value.

So what limit are your refering to as "only one"?

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Feb 2017 16:23:31 -0000

Ooops, my misreading.

This is what happens when we have "MD Type" and "Type" all within the
"metadata":-)

Yes, my mail should read...

We have a hierarchy:
 MD Type (2^8, about to become 2^4 when we add the TTL)
   MD Class (2^16)
      MD Context Header Types (2^7 about to become 2^8)

So I have some observations...
o 2^4 is enough MD types
    There is no MD type for "vendor specific", and I don't believe we
    need one.
    Obviously, the IANA section needs rewriting for the change to 4 bits.
o 2^16 is a lot of MD classes. Really a lot!
   The philosophy appears to be that a context header is distinguished
   by {MD class, type} and that MD class identifies a source of allocations
   of type.
   If so, then yes, we should allow vendors to have a value if (and only if)
   we want to support that kind of non-interoperable exchange between
   SFIs.
   In this case I would *strongly* urge FCFS not Private Use so that it is
   possible to perform diagnostics and know to whom to attribute the
   context header.
   It is probably good to have one or two experimental classes. Not sure
   there is a case for >2.
o 2^8 might not be enough types within a class over time as Med says.
   However, additional classes can be grabbed if the types in one class 
   are depleted.
   We *could* allow vendor-specific types within the IETF/NSH class,
   but I hope not (if the vendor can grab a whole class)
   It is still probably worth having experimental types in the IETF/NSH
   class, and I can imagine 4 being a good number.

Thanks,
Adrian

> From: Joel Halpern Direct [mailto:[email-masked]]
> Sent: 20 February 2017 13:52
> To: [email-masked]; [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Feb 2017 11:59:56 -0500

Just to make sure I understand your suggestion regarding MD Class,
we could take a large portion of the range and declare it to be FCFS, 
with a note that this is expected to be used by vendors for their own 
proprietary or pre-standard extensions?
On the theory that there probably are not even 1000 different vendors 
who need code points?

While I understand your point about interoperability, we also are not in 
a position to enumerate all desired metadata.  So having a way for folks 
to deploy stuff we have not enumerated seems helpful.

Should we have any statement about how vendors should document Type 
codes within their assigned MD Class?

Yours,
Joel

---

From: <[email-masked]>
Date: Tue, 21 Feb 2017 06:34:11 +0000

Hi all, 

One comment inline.

Cheers,
Med

> Envoyé : lundi 20 février 2017 17:24
> À : 'Joel Halpern Direct'; [email-masked]

[Med] Grabbing one additional MD Class would be OK for the IETF assigned MD.Type values. However, for MD classes that want to reuse an existing registry, this is problematic because the 1:1 mapping won't be easy to define. 

* Having a longer type field will allow to map the whole IPFIX registry (https://tools.ietf.org/html/rfc7012#section-4). IPFIX ElementID are in the range 1-32767.
* Having a longer type field will allow to map the whole table in Section 7.1 of http://www.etsi.org/deliver/etsi_ts/129200_129299/129230/12.06.00_60/ts_129230v120600p.pdf in one single MD Class to be called, for example, 3GPP.    

>    class, and I can imagine 4 being a good number.

[Med] I suggest:
* no vendor-specific values are allowed in the IETF Classes.  
* using few shared MD Classes for this usage. Type values can be assigned in that range following an FCFS approach. Vendor-specific values can be then assigned without consuming an MD class. One shared MD Class can be created in the NSH document to anticipate vendor-specific requests.

> > > AFAICS only one "optional variable length metadata" can be present in
> an
> NSH.
> > >
> > >> space for vendors.  But how would we assign values to vendors for
> their
> use?
> > >>
> > >> Yours,
> > >> Joel
> > >>