Update of the Pseudowire Control-Word Negotiation Mechanism
draft-ietf-pwe3-cbit-negotiation-05

[Ballot comment]
This is non-blocking:

To start, realize that I am NOT well versed in PWE3 technology, and please tell me if what I'm asking about would simply be clearly understood by those who are.

In addition to Adrian's rewrite of Section 3 bullet "i" (which I support), I find some other wording clarifications in Section 3 necessary to the understanding of this document:

  Note: the FEC element in label request message should be the PE's
  local FEC element.  Only if FEC element in label request message
  could bind together with peer PE's local FEC element, the peer PE
  sends label mapping with its bound local FEC element and label as a
  response.

I do not understand these two sentences.  What is "should be" in the first sentence?  Is it, or is it not?  I'm not necessarily suggesting changing this to 2119 language, but that you make it clear what you're saying.  The second sentence is just unparseable, and I'm not at all sure that I understand what it's trying to say.

  When Local PE changes the use of control word from PREFERRED to NOT
  PREFERRED, Local PE would be able to re-negotiate the Control Word to
  be not used following the procedures defined in [RFC4447], and no
  label request message to peer PE will be needed.  In that case, Local
  PE will always send new label mapping with C-bit reflecting the
  locally configured preference for use of Control Word.

I'm having a hard time with this paragraph, and don't think I understand it.  I think "to be not used" may be throwing me... apart from its not parsing, I *think* it says that you won't use the Control Word (please use consistent capitalization -- you have it capitalized and not capitalized in the same sentence here) in this case.  Is that right?  Does that make sense?  Then the next sentence talk about using the Control Word.  Please rephrase this paragraph, or assure me that anyone who understands PWE3 will get this, and that's just not me.

I *very* much appreciate and applaud the work done by our non-native-speaking colleagues.  With that in mind, I strongly suggest an editing pass by a native speaker who is familiar with the technology, to correct articles, number, tenses, and punctuation.  The RFC Editor will do this, of course, but they are not technology experts, and may make errors that will be hard to detect during AUTH48.

The Documnet Shepherd provided the following clarification concerning his evaluation of consensus:

My statement in the writeup was based for the most part on reaction and discussion during various WG meetings plus the favorable discussion during WG adoption. In particular, the following is from IETF 82, when it was last discussed at a meeting:

          Is the document ready for working group last call?
          The chairs will discuss after taipei and if ready it will go to last
          call and if not they will discuss with authors.  No issues anticipated
          as sufficient discussion was present on the list and the document is
          felt to be in good shape.

There were no comments to the contrary at the meeting, and also during WG last call. The absence of dissent is consensus, when you're not taking votes.

In addition, the authors have been exemplary in responding to and resolving all received comments.

In a case like this, what's the alternative, and I ask this seriously – do we not pass WG last call because people aren't enthusiastic enough? The time to show enthusiasm is during WG adoption, which we saw. The purpose of WG last call is to root out the last bugs and give people a chance to say if they feel it's not yet ready. IMHO, we passed that hurdle.

[Ballot discuss]
To start, realize that I am NOT well versed in PWE3 technology, and please tell me if what I'm asking about would simply be clearly understood by those who are.

In addition to Adrian's rewrite of Section 3 bullet "i" (which I support), I find some other wording clarifications in Section 3 necessary to the understanding of this document:

  Note: the FEC element in label request message should be the PE's
  local FEC element.  Only if FEC element in label request message
  could bind together with peer PE's local FEC element, the peer PE
  sends label mapping with its bound local FEC element and label as a
  response.

I do not understand these two sentences.  What is "should be" in the first sentence?  Is it, or is it not?  I'm not necessarily suggesting changing this to 2119 language, but that you make it clear what you're saying.  The second sentence is just unparseable, and I'm not at all sure that I understand what it's trying to say.

  When Local PE changes the use of control word from PREFERRED to NOT
  PREFERRED, Local PE would be able to re-negotiate the Control Word to
  be not used following the procedures defined in [RFC4447], and no
  label request message to peer PE will be needed.  In that case, Local
  PE will always send new label mapping with C-bit reflecting the
  locally configured preference for use of Control Word.

I'm having a hard time with this paragraph, and don't think I understand it.  I think "to be not used" may be throwing me... apart from its not parsing, I *think* it says that you won't use the Control Word (please use consistent capitalization -- you have it capitalized and not capitalized in the same sentence here) in this case.  Is that right?  Does that make sense?  Then the next sentence talk about using the Control Word.  Please rephrase this paragraph, or assure me that anyone who understands PWE3 will get this, and that's just not me.

[Ballot comment]
This is non-blocking:
I *very* much appreciate and applaud the work done by our non-native-speaking colleagues.  With that in mind, I strongly suggest an editing pass by a native speaker who is familiar with the technology, to correct articles, number, tenses, and punctuation.  The RFC Editor will do this, of course, but they are not technology experts, and may make errors that will be hard to detect during AUTH48.

[Ballot discuss]

  The Gen-ART Review by Elwyn Davies on 19-Jun-2012 says:
  >
  > Not ready. The proposal for the NOT PREFERRED to PREFERRED
  > transition case does not appear to be compatible with the existing
  > RFC 4447 standard in the way stated and there are a number of other
  > minor issues.
  >
  This lead to a dialogue between the authors and Elwyn.  That dialogue
  has not completed as yet, but it is clear to me that some document
  changes will be needed in the end.  I'll clear this DISCUSS position
  when the dialogue reaches closure and the document updates are made.

[Ballot comment]
General: If this draft is about generic renegotiation it should just say that ;)

This is just word smthing:

(section:change - a=abstract)

- a and s1:

OLD:

The control word negotiation mechanism specified in RFC4447 has a problem when PE changes the preference for the use of control word from PREFERRED to NOT-PREFERRED. This draft updates RFC4447 by introducing a message exchanging mechanism to resolve this control word negotiation issue.

NEW:

The control word negotiation mechanism specified in RFC4447 does not support renegotiation of a Provider Edges (PEs) when its changed from NOT-PREFERRED to PREFERRED.  This draft updates RFC4447 by introducing a renegotiation mechanism.

use [RFC4447] in s1.  if it's generic then you could drop the "when ..." bit.

- I think you cold delete s2 entirely and add the following paragraph to s1:

The negotiation mechanism described in [RFC4447] addresses receipt of Label Mapping before one is sent and if a Label Mapping message has not been received.  It does not support PE's changing their control word setting after the PW has been established from NOT-PREFERRED to PREFERRED.

- s3, 1st para:

OLD:

In order to resolve above problem, the control word re-negotiation mechanism as described in [RFC4447] section 6 is updated by adding label request message.

NEW:

[RFC4447] section 6.2 is updated to add the control word re-negotiation mechanism described in this section.

- s3.1, bullet i: Couldn't parse it.

[Ballot discuss]
I'm confused is this a generic control word renegotiation mechanism (I think it is) or is it just to change from preferred to not preferred or not preferred to preferred?

[Ballot comment]
This is just word smthing:

(section:change - a=abstract)

- a and s1:

OLD:

The control word negotiation mechanism specified in RFC4447 has a problem when PE changes the preference for the use of control word from PREFERRED to NOT-PREFERRED. This draft updates RFC4447 by introducing a message exchanging mechanism to resolve this control word negotiation issue.

NEW:

The control word negotiation mechanism specified in RFC4447 does not support renegotiation of a Provider Edges (PEs) when its changed from NOT-PREFERRED to PREFERRED.  This draft updates RFC4447 by introducing a renegotiation mechanism.

use [RFC4447] in s1.  if it's generic then you could drop the "when ..." bit.

- I think you cold delete s2 entirely and add the following paragraph to s1:

The negotiation mechanism described in [RFC4447] addresses receipt of Label Mapping before one is sent and if a Label Mapping message has not been received.  It does not support PE's changing their control word setting after the PW has been established from NOT-PREFERRED to PREFERRED.

- s3, 1st para:

OLD:

In order to resolve above problem, the control word re-negotiation mechanism as described in [RFC4447] section 6 is updated by adding label request message.

NEW:

[RFC4447] section 6.2 is updated to add the control word re-negotiation mechanism described in this section.

- s3.1, bullet i: Couldn't parse it.

[Ballot discuss]
(Edit to remove piece of Discuss related to process)

The Abstract could usefully say that this document updates both 4447
and 6073.

The Introduction talks of updating 4447 but does not mention 6073. A
clear statement of what is updated in 6073 is needed.

---

Section 3.1

      -i.  Local PE MUST send a label withdraw message to remote PE if
      it has previously sent a label mapping, and label release message
      to remote PE, and wait until receiving a label release from the
      remote PE.

I'm afraid that this can't be parsed. Does it mean:

      -i.  If a PE has previously sent a Label Mapping message to a
          remote PE, it MUST send a Label Withdraw message to the
          remote PE, send a Label Release message to remote PE, and
          wait until it receives a Label Release message from the
          remote PE.


---

I agree with Section 4 as it applies to single hop PWs, but it is not
consistent with the text in Section 3. This is because Section 3
includes normative description of behavior of the legacy node that
Section 4 claims will work without modification. Viz.

  When the remote PE successfully processed the label withdraw and
  label release, and removed the remote label binding, it MUST reset
  its use of control word with the locally configured preference, and
  send label mapping as a response of label request with locally
  configured preference for use of control word.

I think you need to reword this to show that it represents no change in
behavior of the remote PE (i.e. PE1 in your example).
       
However, the case for multi-hop PWs seems less simple. I think you
describe behavior required at adjecent S-PEs. Does this come for free or
is there a requirement to upgrade all S-PEs to support this function?

[Ballot comment]

- Adrian's process questions in his discuss seem reasonable to me,
as does the question about how this updates 6073.

- PE could usefully be expanded in section 1.

- The abstract talks about the PREFERRED->NOT-PREFERRED transition,
but section 2 talks about the NOT-PREFERRED->PREFERRWED transition
at PE2. That confused me, since the abstract implies only the
PREFERRED->NOT-PREFERRED transition is problematic.

- Is it "NOT PREFERRED" or "NOT-PREFERRED"? Pick one.

- Section 5: I assume the security considerations from 4447 and/or
6073 apply here as well. Worth saying?

[Ballot discuss]
(Edit to remove a piece of stray text)

The Abstract could usefully say that this document updates both 4447
and 6073.

The Introduction talks of updating 4447 but does not mention 6073. A
clear statement of what is updated in 6073 is needed.

---

Section 3.1

      -i.  Local PE MUST send a label withdraw message to remote PE if
      it has previously sent a label mapping, and label release message
      to remote PE, and wait until receiving a label release from the
      remote PE.

I'm afraid that this can't be parsed. Does it mean:

      -i.  If a PE has previously sent a Label Mapping message to a
          remote PE, it MUST send a Label Withdraw message to the
          remote PE, send a Label Release message to remote PE, and
          wait until it receives a Label Release message from the
          remote PE.


---

I agree with Section 4 as it applies to single hop PWs, but it is not
consistent with the text in Section 3. This is because Section 3
includes normative description of behavior of the legacy node that
Section 4 claims will work without modification. Viz.

  When the remote PE successfully processed the label withdraw and
  label release, and removed the remote label binding, it MUST reset
  its use of control word with the locally configured preference, and
  send label mapping as a response of label request with locally
  configured preference for use of control word.

I think you need to reword this to show that it represents no change in
behavior of the remote PE (i.e. PE1 in your example).
       
However, the case for multi-hop PWs seems less simple. I think you
describe behavior required at adjecent S-PEs. Does this come for free or
is there a requirement to upgrade all S-PEs to support this function?

---

The write-up says:
  This draft had strong consensus in the WG, and received good comments
  at the various stages of its development.

I may be missing some emails from my archive.

I can see a large volume just before the I-D was polled for adoption.
Most of these emails were questioning or critical.

The poll for adoption was mainly supportive, but some quesitons were
asked.

After adoption I only see:
- 00 posted
- 01 posted
- note from an author
- 02 posted
- 03 posted
- WG last call started
- WG last call ended
- publication request
- IETF last call
- 04 posted

This does NOT represent strong consensus in the WG, nor good comments at
the various stages of its development. It is hard to see it as anything
other than complete neglect by the WG.

There is no way to make this part of my Discuss actionable for the
authors. I need to hear from the WG chairs and AD how they justify their
statements.

[Ballot discuss]
The Abstract could usefully say that this document updates both 4447
and 6073.

The Introduction talks of updating 4447 but does not mention 6073. A
clear statement of what is updated in 6073 is needed.

---

Section 3.1

      -i.  Local PE MUST send a label withdraw message to remote PE if
      it has previously sent a label mapping, and label release message
      to remote PE, and wait until receiving a label release from the
      remote PE.

I'm afraid that this can't be parsed. Does it mean:

      -i.  If a PE has previously sent a Label Mapping message to a
          remote PE, it MUST send a Label Withdraw message to the
          remote PE, send a Label Release message to remote PE, and
          wait until it receives a Label Release message from the
          remote PE.


---

Section 2

Since it is PE2 that is the downstream node that sends the Label
Withdraw, there is an error in bullet 2

  2.  The negotiation result for the control word of this PW is used,
      and PE1 sends label mapping with C-bit=0 finally according to
      [RFC4447] section 6.2.

The downstream node will send the Label Mapping so s/PE1/PE2/

---

I agree with Section 4 as it applies to single hop PWs, but it is not
consistent with the text in Section 3. This is because Section 3
includes normative description of behavior of the legacy node that
Section 4 claims will work without modification. Viz.

  When the remote PE successfully processed the label withdraw and
  label release, and removed the remote label binding, it MUST reset
  its use of control word with the locally configured preference, and
  send label mapping as a response of label request with locally
  configured preference for use of control word.

I think you need to reword this to show that it represents no change in
behavior of the remote PE (i.e. PE1 in your example).
       
However, the case for multi-hop PWs seems less simple. I think you
describe behavior required at adjecent S-PEs. Does this come for free or
is there a requirement to upgrade all S-PEs to support this function?

---

The write-up says:
  This draft had strong consensus in the WG, and received good comments
  at the various stages of its development.

I may be missing some emails from my archive.

I can see a large volume just before the I-D was polled for adoption.
Most of these emails were questioning or critical.

The poll for adoption was mainly supportive, but some quesitons were
asked.

After adoption I only see:
- 00 posted
- 01 posted
- note from an author
- 02 posted
- 03 posted
- WG last call started
- WG last call ended
- publication request
- IETF last call
- 04 posted

This does NOT represent strong consensus in the WG, nor good comments at
the various stages of its development. It is hard to see it as anything
other than complete neglect by the WG.

There is no way to make this part of my Discuss actionable for the
authors. I need to hear from the WG chairs and AD how they justify their
statements.

[Ballot comment]
Please s/draft/document/

---

Please request the RFC Editor to not split Appendix A across a page
break.

---

Please capitalise all mesage names to be consistent with RFC 5036, and
include the word "message".

IANA has reviewed draft-ietf-pwe3-cbit-negotiation-03, which is currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Pseudowire Control Word Negotiation Mechanism Update) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Pseudowire Control Word Negotiation Mechanism Update'
  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 2012-06-15. 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 describes the problem of control word negotiation
  mechanism specified in [RFC4447].  Based on the problem analysis, a
  message exchanging mechanism is introduced to solve this control word
  negotiation issue.  This document is to update [RFC4447] control word
  negotiation mechanism.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-cbit-negotiation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-cbit-negotiation/ballot/


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

Document Writeup for draft-ietf-pwe3-cbit-negotiation-03

As required by RFC 4858 , this is the current template
for the Document Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard. This updates a Standards Track RFC. Yes, the title page
header is correct.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document solves a particular problem with the control word negotiation
mechanism specified in RFC 4447. Based on the problem analysis, a
message exchanging mechanism is introduced to solve the control word
negotiation issue. This document updates the RFC 4447 control word
negotiation mechanism. This update is fully backwards compatible with
existing implementations.

Working Group Summary

This draft had strong consensus in the WG, and received good comments at
the various stages of its development.

Document Quality

There is at least one known vendor implementation of the draft (the
reporter says "Our product manager asked me to thank IETF&PWE3 to help to
solve this problem"), and other vendors have expressed implementation plans.

Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

Andrew Malis and Stewart Bryant.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd reviewed the draft for quality. It's a relatively
short draft and the algorithm is easy to follow. Because the lead editor is
not a native English speaker, the RFC Editor will probably do a minor
editorial cleanup of the text from an English language perspective.

Note that the draft currently has seven authors. Two of the authors,
Vishwas Manral and Reshad Rahman, have indicated that they are willing to
be moved to the acknowledgements section.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns. It's been presented several times in the WG meetings and
there's been good discussion on the list.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No, there is no known IPR concerning this draft.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong consensus in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

It passes nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This RFC updates RFC 4447. This is included in the title page header, the
abstract, and the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA actions.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A