Subject: [mpls] draft-ietf-mpls-ldp-iana

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Oct 2011 18:22:35 +0100

Hi WG, 

I started my review of this document and have a fairly fundamental question for
the WG.

The document looks at the IANA registries for LDP and compares with the protocol
spec (RFC5036). It observes that there are some fields in the protocol spec
marked as "reserved" and that there is no clear statement of how those fields
can be used in future protocol extensions.

The problem I am having is that the fields are reserved, not unassigned. If they
were named fields with known uses (e.g. bit fields) it would make sense to
define an assignment policy, say that the fields are currently unassigned, and
use the combination of the IESG and the IANA to police future use.

But what I think you are trying to do is state what the RFC means by "reserved".
That is a fine thing to do in a draft if you believe it is necessary (I would
note that no-one has previously found it to be necessary, but reserved fields
are often scoped as MBZ to allow future extensibility).  In practice, a field
that is "reserved" in a standards track RFC is, well, erm, reserved. You can't
suddenly start using the field without an RFC. (Just as you could not change a
message format to add another field.)

However, you cannot use IANA to police reserved fields. IANA manages code point
registries, not protocol behavior. What you are effectively doing in this I-D is
creating a negative assignment: you are asking IANA to not create a new registry
for a protocol field (as yet unknown) in a specific spot in a certain TLV or
message. That's hard for IANA because they don't care where or how their
registries are encoded in messages. indeed, Some registries are used in multiple
protocol fields.

To say it another way, I read the document as saying "Ooops, we defined a couple
of fields that people might start making allocations from, but which
don't have IANA registries." But what I sense is actually the intention is
"Hmmm, there are some reserved fields and we would like to control how those
fields might get used in the future."

So, coming back again to what I think it is you want to achieve: should this
document simply be an update to 5036 that says "The following fields that
are marked as 'reserved' in [RFC5036] are not to be used for new protocol
mechanisms except through RFCs that achieve IETF consensus."

And finally, my question. What is this document *really* trying to achieve? Why
do you actually need it? 

There is one exception to all of this. The Len field of the Frame Relay Label
TLV could have a registry defined.

Thanks,
Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 25 Oct 2011 12:44:51 -0500

Adrian,

The one-liner response to your "Why do you actually need it?", more
later: for draft-ietf-mpls-ldp-gtsm, we need to assign a bit in the
Common Hello Parameter TLV for which there is no allocation policy --
that's the whole motivation. WG consensus was to, since we are doing
that, we might as well proactively fill in all the gaps in RFC 5036. 

Hope that clarifies,

-- Carlos.
	
-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2011 1:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-mpls-ldp-iana

Hi WG, 

I started my review of this document and have a fairly fundamental
question for
the WG.

The document looks at the IANA registries for LDP and compares with the
protocol
spec (RFC5036). It observes that there are some fields in the protocol
spec
marked as "reserved" and that there is no clear statement of how those
fields
can be used in future protocol extensions.

The problem I am having is that the fields are reserved, not unassigned.
If they
were named fields with known uses (e.g. bit fields) it would make sense
to
define an assignment policy, say that the fields are currently
unassigned, and
use the combination of the IESG and the IANA to police future use.

But what I think you are trying to do is state what the RFC means by
"reserved".
That is a fine thing to do in a draft if you believe it is necessary (I
would
note that no-one has previously found it to be necessary, but reserved
fields
are often scoped as MBZ to allow future extensibility).  In practice, a
field
that is "reserved" in a standards track RFC is, well, erm, reserved. You
can't
suddenly start using the field without an RFC. (Just as you could not
change a
message format to add another field.)

However, you cannot use IANA to police reserved fields. IANA manages
code point
registries, not protocol behavior. What you are effectively doing in
this I-D is
creating a negative assignment: you are asking IANA to not create a new
registry
for a protocol field (as yet unknown) in a specific spot in a certain
TLV or
message. That's hard for IANA because they don't care where or how their
registries are encoded in messages. indeed, Some registries are used in
multiple
protocol fields.

To say it another way, I read the document as saying "Ooops, we defined
a couple
of fields that people might start making allocations from, but which
don't have IANA registries." But what I sense is actually the intention
is
"Hmmm, there are some reserved fields and we would like to control how
those
fields might get used in the future."

So, coming back again to what I think it is you want to achieve: should
this
document simply be an update to 5036 that says "The following fields
that
are marked as 'reserved' in [RFC5036] are not to be used for new
protocol
mechanisms except through RFCs that achieve IETF consensus."

And finally, my question. What is this document *really* trying to
achieve? Why
do you actually need it? 	

There is one exception to all of this. The Len field of the Frame Relay
Label
TLV could have a registry defined.

Thanks,
Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 25 Oct 2011 12:50:54 -0500

Adrian,

BTW: The distinction between the Unassigned and Reserved labels appears
in RFC 5226, which published after RFC 5036. RFC 5036 points to RFC
2434, which lacks that distinction.

Thanks,

-- Carlos. 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2011 1:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-mpls-ldp-iana

Hi WG, 

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Oct 2011 18:58:35 +0100

I understand, Carlos.

Ask yourself the question whether the field in the TLV marked "reserved" is
already a bit field? If it is, you are right to want to define the allocation
policy and establish a registry.  If it is not (but is simply a reserved field)
then you have to decide whether you are allocating a new protocol field from the
reserved portion of the TLV, or are redefining the whole reserved field as a bit
field.

You might help yourself to consider the question by considering what you would
have done had you needed an 8-bit integer, not a flag. Could you have defined
this from the reserved part of the TLV? Answer the question before you dreamed
of draft-ietf-mpls-ldp-gtsm, and afterwards.

Cheers,
Adrian

> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: 25 October 2011 18:45
> To: [email-masked]; [email-masked]
> Subject: RE: draft-ietf-mpls-ldp-iana
> 
> Adrian,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Oct 2011 19:03:42 +0100

I think you are mistaking the assignment policy "reserved" defined in 5226, with
a field in a protocol element that is labelled as "reserved".

The former is how a code point is described in a registry.
The latter is how a field that has no associated use or registry is described in
an RFC.

Adrian

> Sent: 25 October 2011 18:51

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 26 Oct 2011 22:07:55 -0400

Hi Adrian,

The fields marked "reserved" are atomic fields without syntax or
semantics. draft-ietf-mpls-ldp-iana does not attempt to define the field
or start using it. But without it, there are no rules as to what is
needed for something to start using them. There is a potential
chicken-egg as well.

This said, I do see your point now, as while I re-read
draft-ietf-mpls-ldp-iana, the current text can be read to be making the
assumption that a 6-bit field is a bit-field.

On the other hand, the (proposed) allocation policy of "IETF Review" is
basically (and purposely) agreeing with your intent below, in that an
RFC with IETF consensus is needed.

Or said a different way, the same way that a registry sets specific
allocation policies for ranges of values to be used for vendor-private,
we are trying to specify the (yet unspecified) policy for how to update
these "Reserved" fields, and explicitly state that an RFC that achieves
IETF consensus is required.

So perhaps, text like the following:

2.4.  Common Session Parameters TLV

   There are six Reserved bits in the Common Session Parameters TLV (see
   Section 3.5.3 of [RFC5036]).  Allocations from these bits are made
   via IETF Review [RFC5226].  Previously, there was no rule for
   allocation of these bits.

Should instead be:

2.4.  Common Session Parameters TLV

   There is a six-bit Reserved field in the Common Session Parameters
   TLV (see Section 3.5.3 of [RFC5036]).  Definition of this field is
   made via IETF Review [RFC5226].  Previously, there was no rule for
   using the bits in this Reserved field.

Or do you think that the update should rename the fields to "Undefined"
or simply "MBZ"?

Thanks,

-- Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 26 Oct 2011 22:08:17 -0400

Hi Adrian,

You are right, I was mistaking the two uses of "reserved". Agreed.

BTW, this prompted me to grep "reserved" from RFC 5036, where it is also
using the word "reserved" with multiple semantics: i. "reserved" as a
protocol field being reserved (and MBZ, implying potential future
extensibility); ii. "reserved" as values from a field being unassigned
meaning (e.g., FR Len); and iii. range of values as "reserved" in a
registry for a particular allocation scheme. These are the same
"reserved" instances from RFC 3036.

Thanks,

-- Carlos.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 27 Oct 2011 09:31:15 -0400

> needed for something to start using them.

Since there are currently no IANA registries for the fields in question, it
is currently impossible for IANA to make any assignments to those fields.
As those fields are part of an IETF standard protocol, a redefinition of
those fields could only be accomplished by a "standards action".  So what is
wrong with the status quo?

The only issue I see is that if one wants to use one of the currently unused
bits, there is no central place to go to see if any other standards-track
RFC is already using it.  I think this is a real issue, but I'm not sure it
can be addressed by creating an IANA registry.  IANA will ask not only for
the allocation policy, but for the range of values that are assignable.  If
we don't know whether we may want to use a field as a bit field or as 13-bit
integer, I don't know how we would provide that information to them.

Maybe all that is needed is to have the GTSM draft indicate that it updates
RFC 5036, and mention in the abstract and introduction that it uses a bit
that is reserved in RFC 5036.

It's also hard to see the point of creating registries for "ATM Label TLV",
"Frame Relay Label TLV".  The first standards track RFC that needs these
registries can request them.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Oct 2011 15:00:34 +0100

Thanks Eric,

I think that pretty much captures it.

We have previously had similar "problems" when multiple I-Ds have started to
allocate flags from a reserved space. We have usually handled this by turning
all of part of the reserved space into a flags field and asking IANA to manage
it. But this has often only been necessary when there is a flurry of multiple
I-Ds attacking the same area.

In this case, I think the new I-D should simply define a new bit flag, show
where it fits into the TLV structure, and move on.

Cheers,
Adrian

> From: Eric Rosen [mailto:[email-masked]]
> Sent: 27 October 2011 14:31
> To: Carlos Pignataro
> Cc: [email-masked]; [email-masked];
[email-masked]
> Subject: Re: [mpls] draft-ietf-mpls-ldp-iana
> 
>

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 27 Oct 2011 10:57:19 -0400

Eric,

This makes sense and I'm totally OK with that path forward. I'll wait a
bit to see if there's more WG input.

Adrian,

Thanks for initially bringing this up -- just for clarity: we can have
the GTSM draft update RFC 5036 and define a single G bit, and
additionally were you suggesting that it would be useful to also i.
define reserved as bitfield for the Common Hello/Session Parameters (I
think not, but asking for completeness); ii. provide a statement (as you
previously suggested) that "The following fields that are marked as
'reserved' in [RFC5036] are not to be used for new protocol mechanisms
except through RFCs that achieve IETF consensus"; or iii. do nothing else?

I am a bit sensitive to the potential issue that Eric and you also
highlight, which is that there is no central place to know what's used.
Frankly, I think that that was one of the strongest implied motivations
here. So checking RFC 5036 an implementor sees:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0| Common Hello Parms(0x0400)|      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Hold Time                |T|R| Reserved                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And unless he or she first sees, second understands, and third follows
the "Updates" link chain, they would not immediately know that there is
a bit that was claimed to be used. In a way, I've used the IANA pages
for that.

What's your sense? Should a nibble be turned into a bitflag and given to
IANA (so we see bits "T, R, G (future), unassigned")? This would perhaps
only make sense for Common Hello/Session Parameters? Or even turn the
existing ones?

Thanks,

-- Carlos.

---

From: "t.petch" <[email-masked]>
Date: Thu, 27 Oct 2011 16:30:24 +0200

----- Original Message ----- 
From: "Eric Rosen" <[email-masked]>
To: "Carlos Pignataro" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, October 27, 2011 3:31 PM
> registries can request them.

I agree; this I-D, which I regret not having read earlier else I would have 
opposed its adoption seems to be setting in concrete matters that the 
editors of RFC5036, in their wisdom, left open until and when there 
was a need to be more specific, and, with the exception
of one small item for GTSM, that wisdom appears, to me, still to be wise.

Tom Petch

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 27 Oct 2011 11:15:12 -0500

Similar states happen for other protocols as well. For example with the
IPv6 ND Router Advertisement flags, where RFC2461 left a 6-bit Reserved
opaque field next to two bit-flags (see
<http://tools.ietf.org/html/rfc4861#section-4.2>), and then other RFCs
(RFC3775, RFC4191, RFC4389) define more bits from that Reserved.
Finally, RFC5175 rationalizes all this in an IANA Registry, and further
extends the bit-flag.

But, to Eric's point, note that here an Experimental RFC 4389 defines a
"Reserved" bit from a Std-track one. So it might not be automatically
evident that the only redefinition path is as per "standards action".

Seems like the proposed path forward good.

Thanks,

-- Carlos.
PS: Tom: you may have also missed
<http://www.ietf.org/proceedings/80/slides/mpls-16.pdf> to oppose?
Hindsight is 20/20.

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: Thursday, October 27, 2011 10:30 AM
To: Eric Rosen (erosen); Carlos Pignataro (cpignata)
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] draft-ietf-mpls-ldp-iana

----- Original Message ----- 
From: "Eric Rosen" <[email-masked]>
To: "Carlos Pignataro" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, October 27, 2011 3:31 PM
> registries can request them.

I agree; this I-D, which I regret not having read earlier else I would
have 
opposed its adoption seems to be setting in concrete matters that the 
editors of RFC5036, in their wisdom, left open until and when there 
was a need to be more specific, and, with the exception
of one small item for GTSM, that wisdom appears, to me, still to be
wise.

Tom Petch