Updates to MPLS Transport Profile Linear Protection
draft-ietf-mpls-psc-updates-06

[Ballot comment]
I'm clearing my Discuss assuming something like Adrian's proposed text makes it into the doc.

Adrian's proposed text is :

OLD
2.3.2.  Well-formed but unexpected TLV

  If a message is deemed to be properly formed, an implementation
  SHOULD check all TLVs to ensure that it knows what to do with them.
  A well-formed but unknown TLV value MUST be ignored, and the rest of
  the message processesed as if the ignored TLV did not exist.  An
  implementation detecting a malformed TLV SHOULD alert the operator as
  described in Section 2.3.1.
NEW
2.3.2.  Well-formed but unknown or unexpected TLV

  If a message is deemed to be properly formed, an implementation
  SHOULD check all TLVs to ensure that it knows what to do with them.
  A well-formed but unknown or unexpected TLV value MUST be
  ignored, and the rest of the message processed as if the ignored TLV
  did not exist.  An implementation detecting a malformed TLV SHOULD
  alert the operator as  described in Section 2.3.1.
END

My Discuss was:

---

This should be a easy Discuss to clear, especially if I don't understand what's going on ...

2.3.2.  Well-formed but unexpected TLV

  If a message is deemed to be properly formed, an implementation
  SHOULD check all TLVs to ensure that it knows what to do with them.
  A well-formed but unknown TLV value MUST be ignored, and the rest of
  the message processesed as if the ignored TLV did not exist.  An
  implementation detecting a malformed TLV SHOULD alert the operator as
  described in Section 2.3.1.

"unexpected" and "unknown" don't mean quite the same thing to me (I think from the paragraph you mean "unknown"), but the Discuss is that the last sentence is saying what should happen if the TLV is malformed, which was 2.3.1, and the section doesn't say what to do if the TLV is unexpected, or unknown or whatever this section turns out to be about. Cut and paste error from someplace?

Could you take a look at this more closely?

[Ballot discuss]
This should be a easy Discuss to clear, especially if I don't understand what's going on ...

2.3.2.  Well-formed but unexpected TLV

  If a message is deemed to be properly formed, an implementation
  SHOULD check all TLVs to ensure that it knows what to do with them.
  A well-formed but unknown TLV value MUST be ignored, and the rest of
  the message processesed as if the ignored TLV did not exist.  An
  implementation detecting a malformed TLV SHOULD alert the operator as
  described in Section 2.3.1.

"unexpected" and "unknown" don't mean quite the same thing to me (I think from the paragraph you mean "unknown"), but the Discuss is that the last sentence is saying what should happen if the TLV is malformed, which was 2.3.1, and the section doesn't say what to do if the TLV is unexpected, or unknown or whatever this section turns out to be about. Cut and paste error from someplace?

Could you take a look at this more closely?

[Ballot comment]
From the title, abstract, introduction, I see words such as updates, rules, recommendations, corrections, clarifications.

I'm unable to tell if there will be backward compatibly issues between this future RFC and RFC6378
And sorry, I haven't reviewed all the technical details of the update, to make up my mind.
Is this document just text clarifications, or should http://tools.ietf.org/html/rfc5706#section-2.3 be considered?
If the former, clarify this early in the document.
Otherwise, discuss the migration path.

I was about to file a DISCUSS on this, but a quick discussion was beneficial.
He wrote:

    2.1 Just a statement for clarity
    2.2 Just a statement for clarity
    2.3 Clarifies error handling. Might change behavior s.t. a broken message previously accepted is now rejected. This is not a b/w compatibility issue
    3. This could change implementation behavior (if the previous implementer was a literalist fool), but the impact is to make a broken implementation work, so that is not a b/w compatibility issue
    4. Describes how to behave to achieve interop or report inability to interop. Old implementations may have winged it, but probably never had the issue because mismatches would not actually have happened. No b/w compatiblity issues.
    5. This fixes a bug in an obscure double race condition. In the event that a pair of old implementations hit this case they would have frozen, so fixing it is not a b/w compatiblity issue.
    6. Is effectively a statement for clarity. Working implementation I know f already do this. I do know a broken implementation that doesn't do this, with the result that it simply doesn't work. So b/w compatibility is not an issue.

I now understand that there are no "backward compatibility issues".
Simply add: "This document does not introduce backward compatibility issues with implementations of RFC 6378"

[Ballot discuss]
In 2.1:
  All integer fields in the PSC TLV are encoded as unsigned integers in
  network bit order.

Shouldn't this be "network byte order"? I know Barry already caught this, but he didn't raise it as a DISCUSS, and since it has to be correctly interpreted for interoperability, I'm doing so. Please let me know if I've misunderstood.

[Ballot comment]
I have no objection, and I think we should do more clarification documents when we find situations such as this.  I do think this could clarify a bit better, so please consider:

Section 2.1 says "network bit order".  Section 2.2 says "network byte order".  Are they meant to be different things?  If not, pick a consistent term.  In either case, a reference defining the term would be useful, just to be sure -- you're clarifying, so it's better clarify as clearly as possible.

I actually still find Section 2.2 somewhat convoluted, as the mention of "The TLV Length" is unclear -- it seems out of place, there in the middle of the detail about individual TLVs.  May I recommend a bit of reorganization here?:

OLD
  [RFC6378] provides the capability to carry TLVs in the PSC messages.
  This section defines the format to be used by all such TLVs.  All
  fields are encoded in network byte order.

  Type field (T):

  A two octet field that encodes a type value.  The type values are
  recorded in the IANA registry "MPLS PSC TLV Registry".

  Length field (L) :

  A two octet field that encodes the length in octets of the Value
  field.

  The TLV Length is the sum of the lengths of all TLVs in the message.
  The length of a TLV is the sum of the lengths of the three TLV
  fields, i.e., the the length of the value field + 4.

  The value of this field MUST be a multiple of 4.

  Value field (V) :

  The contents of the TLV.  This field MUST be a multiple of 4 octets
  and so may contain explicit padding.
NEW
  [RFC6378] provides the capability to carry TLVs in the PSC messages.
  All fields are encoded in network byte order. Each TLV contains
  three fields, as follows:

  Type field (T):
  A two-octet field that encodes a type value.  The type values
  are recorded in the IANA registry "MPLS PSC TLV Registry".

  Length field (L):
  A two-octet field that encodes the length in octets of the Value
  field.  The value of this field MUST be a multiple of 4.

  Value field (V):
  The payload of the TLV.  The length of this field (which is the
  value of the Length field) MUST be a multiple of 4 octets, and so
  this field may contain explicit padding.

  The length of each single TLV is the sum of the lengths of its
  three fields: the length of the value field + 4.  The overall TLV
  Length field in the PSC message contains the total length of all
  TLVs in octets.
END

[Ballot comment]
This document should probably make reference to
draft-ietf-mpls-tp-psc-itu, although the main reference is, of course,
in the other direction.

I suggest a new 2nd paragraph in Section 1 that reads...

  It should be noted that [I-D.ietf-mpls-tp-psc-itu] contains protocol
  mechanisms for an alternate mode of operating MPLS-TP PSC.  Those
  modes are built on the message structures and procedures of [RFC6378]
  and so, while this document does not update [I-D.ietf-mpls-tp-psc-
  itu], it has an impact on that work through its update to [RFC6378].

You would then need to add [I-D.ietf-mpls-tp-psc-itu] as an Informative
reference.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-psc-updates-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the "MPLS PSC TLV Registry" in the Generic Associated Channel (G-ACh) Parameters registry located at:

http://www.iana.org/assignments/g-ach-parameters/

the value 0 will be changed from "Reserved" to "Reserved, not to be allocated" and, in addition, the references will be changed to both [RFC6378] and [ RFC-to-be ].

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Updates to MPLS Transport Profile Linear Protection'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-04-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document contains four updates to the Protection State
  Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile
  (MPLS-TP) Linear Protection" . Two of the updates correct existing
  behavior.  The third clarifies a behavior which was not explained in
  the RFC, and the fourth adds rules around handling capabilities
  mismatches.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ballot/

No IPR declarations have been submitted directly on this I-D.

AD review
=======
All,

I have done my usual AD review of this document on receiving the
publication request. I find this to be a clear and functional
document. Thanks to Eric for holding the pen and to the reviewers
or their input.

The only comments I have are, I believe, already in hand with Eric.

After these updates the Shepherd write-up will need to be updated
because there will be an additional update to 6378, and there will be
an IANA action document.

Similarly, the text of the I-D that talks about the number of updates
will need to be updated.

I'll put the document into "Revised I-D Needed" state and wait for the
next version.

Thanks for the work,
Adrian

=======

Per my earlier email (fixed for the typo):

> A couple of discussion points on draft-ietf-mpls-tp-psc-itu (which is
> currently in IESG evaluation) have given rise to two small proposed
> additions to draft-ietf-mpls-psc-updates
>
> 1. I think this warrants a very small section of its own...
>
> x.y  PSC TLV Format
>
>  [RFC6378] defines the capability to carry TLVs in the PSC messages.
>  This section defines the format to be used by all such TLVs.
>
>  Type field (T)
>      A two octet field that encodes a type value in network byte
>      order. The type values are recorded in the IANA registry "MPLS
>      PSC TLV Registry".
>
>  Length field (L)
>      A two octet field that encodes the length in octets of the Value
>      field in network byte order. The value of this field MUST be a
>      multiple of 4.
>                                                                         
>  Value field (V)
>      The contents of the TLV. This field MUST be a multiple of 4
>      octets and so may contain explicit padding.
>
> 2. There was a trivial snafu with the 0 value in the "MPLS PSC TLV
> Registry". It was agreed that 0 would be reserved, but this was not
> recorded in RFC 6378. Therefore, the IANA section of draft-ietf-mpls-
> psc-updates should include the text...
>
> IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
> as "Reserved, not to be allocated" and to update the references to
> show [RFC6378] and [This.I-D].  Note that this action provides
> documentation of an action already taken by IANA but not recorded in
> RFC 6378.

---

Would be nice to fix the nits from idnits in the next revision.