Pseudowire Status for Static Pseudowires
draft-ietf-pwe3-static-pw-status-10

IESG:

IANA has reviewed draft-ietf-pwe3-static-pw-status-10.txt and has
the following comments:

IANA understands that, upon approval of this document, there are four IANA
Actions which must be completed.

First, in the Pseudowire Associated Channel Types registry in the
Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Value: 0x0027
Description: PW OAM Message
TLV Follows: No
Reference: [ RFC-to-be ]

IANA notes that this value has been provided early assignment in the registry.
Upon approval of this document, the reference will be changed to [ RFC-to-be ].

Second, in the Pseudowire Switching Point PE Sub-TLV Type registry in
the Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Type: 0x07
Length: 24
Description: Static PW/MPLS-TP PW segment ID of last PW segment traversed
Reference: [ RFC-to-be ]

IANA notes that this value has been provided early assignment in the registry.
Upon approval of this document, the reference will be changed to [ RFC-to-be ].

Third, in the Pseudowire Interface Parameters Sub-TLV type Registry
registry in the Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Parameter: 0x18
ID Length: 4
Description: Generic Protocol Flags
Reference: [ RFC-to-be ]

IANA notes that this value has been provided early assignment in the registry.
Upon approval of this document, the reference will be changed to [ RFC-to-be ].

Fourth, IANA is to create a new "PW Generic Protocol Flags" subregistry of the
Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

The registry is composed of bit strings of length 16. Bit 0 is defined in this
document. Bits 1 through 15 are to be assigned by IANA using the "IETF
consensus" policy as defined in RFC 5226.  There is an initial registration as
follows:

Bit Mask    Description
====================================================================
0x0001    -  S-PE bypass mode                          [ RFC-to-be ]

IANA notes that an early version of this new registry has been created at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

Upon approval of this document, IANA will update the references in this new
registry to [ RFC-to-be ].

IANA understands that these are the only actions that need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Additional Last Call: RFC-to-be 6478, previously draft-ietf-pwe3-static-pw-status-10.txt (Pseudowire Status for Static Pseudowires) to Proposed Standard





Due to technical changes made during AUTH48, the IESG is issuing an

additional Last Call on the following document:



- 'Pseudowire Status for Static Pseudowires'

  as a 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-04-30. 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 specifies a mechanism to signal Pseudowire (PW) status

  messages using an PW associated channel (ACh). Such a mechanism is

  suitable for use where no PW dynamic control plane exits, known as

  static PWs, or where a Terminating Provider Edge (T-PE) needs to send

  a PW status message directly to a far end T-PE. The mechanism allows

  PW OAM message mapping and PW redundancy to operate on static PWs.

  This document also updates rfc5885 in the case when Bi-directional

  Forwarding Detection (BFD) is used to convey PW status signaling

  information.









The file can be obtained via

http://www.rfc-editor.org/authors/rfc6478.txt/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/ballot/





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

[Ballot comment]
Thanks for addressing the technical issue in my DISCUSS. I think that the phrase that precedes the diagram (Figure 2) needs to be corrected syntax-wise:

> The PW Status TLV format almost as defined in [RFC4447],
  and is repeated here for the reader's convenience:

[Ballot discuss]
The Gen-ART Review by Ben Campbell was updated on 31-Oct-2011.
  Ben previously raised a concern about Section 5.3; he asked:  Has the
  work group considered how the retransmit scheme and 30 second refresh
  default will scale to very large deployments?  Seems like this could
  result in a lot of retransmissions.  Ben received two responses to
  this comment.

  Stewart Bryant responded:
  >
  > Are you concerned about the network traffic or the PE load.
  > In the case of the network traffic, this is trivial compared to the
  > data traffic that these systems and their networks are designed to
  > carry.
  >
  > In the case of PE load, the PE is designed to deal with it.

  Luca Martini responded:
  >
  > Yes. that is correct. This will most likely not scale for large
  > deployments. We have another document that addresses this issue.
  > That extension is not necessary for most common small deployments
  > in the order of 100 PWs per access PE.

  Either of these responses seem fine to me, but one of them should
  find its way into the document.

[Ballot comment]
Ari Keränen helped me review this specification and he too was concerned about Section 5.3 (PW OAM status message transmit and receive):

[...] the PW OAM
message containing the PW status TLV needs to be transmitted
repeatedly to ensure reliable message delivery. [...]
A PW OAM message containing a PW status TLV with a new status bit set
or reset, will be transmitted immediately by the PE. The PW OAM
message will then be repeated twice more at an initial interval of
one second.

The message is always sent 3 times during the first 3 seconds? How about
ACKs?

[Ballot comment]
1. I support Russ's DISCUSS

2. In Section 5.3:

  If a malformed TLV,
  or an unknown TLV is received in an PW OAM status message, the TLV
  MUST be ignored, and the PE SHOULD report the event to the operator.


How? SNMP Notifications? Any MIB work planned for this purpose?

[Ballot discuss]
In Section 5.2:

  The PW Status TLV format as defined in [RFC4447], and is
  repeated here for the reader's convenience:

and then:

  The first 2 bits are reserved, and MUST be set to zero on transmit,
  and ignored on receive.

However in RFC 4447, in section 5.4.2 the first two bits of the PW Status TLV are represented as 10.

This seems inconsistent. DO I miss something?

[Ballot discuss]
The Gen-ART Review by Ben Campbell was updated on 31-Oct-2011.
  Ben previously raised a concern about Section 5.3; he asked:  Has the
  work group considered how the retransmit scheme and 30 second refresh
  default will scale to very large deployments?  Seems like this could
  result in a lot of retransmissions.  Ben received two responses to
  this comment.

  Stewart Bryant responded:
  >
  > Are you concerned about the network traffic or the PE load.
  > In the case of the network traffic, this is trivial compared to the
  > data traffic that these systems and their networks are designed to
  > carry.
  >
  > In the case of PE load, the PE is designed to deal with it.

  Luca Martini responded:
  >
  > Yes. that is correct. This will most likely not scale for large
  > deployments. We have another document that addresses this issue.
  > That extension is not necessary for most common small deployments
  > in the order of 100 PWs per access PE.

  Either of these responses seem fine to me, but one of them should
  find its way into the document.

[Ballot comment]
Please consider whether [REDUNDANCY] really needs to be a normative
reference. I don't think you use it in that way.

---

Section 6 and its sub-section could be more careful about whether PWs or
PW segments are switched.

---

4385 and 4447 are messed up in the references section.

[Ballot discuss]
I had real problems with Section 4.

- The mention of MPLS and MPLS-TP is curious since MPLS-TP is just a
  subset of MPLS.

- The text doesn't give a reason for the MUST and MUST NOT

- There is no reference to RFC 6310 which is really the justification
  for this work.

- I really do not think you are updating RFC 5885. If anything, you are
  updating RFC 6310 that says:

    Additionally, such a PE MAY use VCCV-BFD CV for both fault detection
    and status notification (CV types 0x08 and 0x20 [RFC5885]).

  But, frankly, I don't think this is much of an update that is worth
  mentioning.

Here is a shot at updating the text. If you like this, you will need
to remove the "updates RFC 5885" stuff from the rest of the document.

OLD
  The procedures described in this draft are intended for the case
  where PWs are statically configured. These procedures also apply
  equally to both an Multi Protocol Label Switched Packet Switched
  Network (MPLS PSN) , and an Multi Protocol Label Switched Transport
  Profile (MPLS-TP) PSN. Where an LDP control plane exists, LDP MUST be
  used for signaling all PW status messages.  However the OPTIONAL 'S-
  PE' bypass mode described below MAY be used in the presence of an LDP
  control plane.

  This document updates [RFC5885] as follows:

  When BFD is used, and the Pseudowire Status protocol for Static
  Pseudowires described in this document is used BFD MUST NOT be used
  to convey PW status signaling information (CV Types 0x08 and 0x20
  MUST NOT be used).
NEW
  As described in [RFC6310], a PE that establishes an MPLS PW using
  means other than LDP, e.g., by static configuration or by use of BGP,
  MUST support some alternative method of status reporting. The
  procedures described in this document are for use when PWs are
  statically configured and a LDP control plane is not available.

  As defined in [RFC6310], a PE that establishes a PW using LDP and
  that has negotiated use of the LDP status TLV per Section 5.4.3 of
  [RFC4447], MUST use the PW status TLV mechanism for AC and PW status
  and defect notification on that PW. In order to avoid duplicate
  notifications and potentially conflicting notifications, such PEs
  MUST NOT use the mechanisms described in this document for those PWs,
  except that the 'S-PE' bypass mode described in Section 5.5 MAY be
  used in all situations.

  A PE that establishes a PW using LDP and does not negotiate the use
  of the LDP status TLV, MAY use the mechanisms described in this
  document.

  In order to protect against duplicate notifications and potentially
  conflicting notifications, when the Pseudowire Status protocol for
  Static Pseudowires described in this document is used, the BFD-VCCV
  status signaling mechanisms described in [RFC5885] (CV Types 0x08 and
  0x20) MUST NOT be used. VCCV-BFD Connectivity Verification (CV) for
  fault detection (CV types 0x04 and 0x10) MAY still be used.
END

---

Section 5.1

Don't you need to create an IANA registry for the Flags field in the
ACH PW OAM Message Packet Header?

---

Section 5.1 needs to state which TLVs can be present. The first
paragraph of the section implies that only the PW status TLV is present.

---

Section 5.2

  The PW Status TLV format as defined in [RFC4447], and is
  repeated here for the reader's convenience:

    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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Res|    PW Status (0x096A)    |            Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Status Code                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 2: PW Status Message Format.

So, is this the TLV format or the message format?

---

Section 5.2

  To clear a particular status indication, the PE needs to send a new
  PW OAM message containing a PW Status TLV with the corresponding bit
  cleared.

This would be fine if there had been any mention of "corresponding bits"
up to this point (or indeed at any other point) in the document. All I
can find is an identical statement in Seciton 5.3.

Please clarify how a status indication is cleared.

---

Section 5.2

  PW OAM Status Messages MUST NOT be also used as
  a connectivity verification method.

Strike "also" because they must not be used, period.
And I support that, but you need to say what you would do if you sent a
status message and did not receive a message with the A flag set.

---

Section 5.3

There is no discussion of how to handle the refresh timer value when the
A flag is set as introduced in Section 5.1.

---

Section 5.3.1

  The PE receiving a PW OAM message containing a PW status message can
  acknowledge the PW status message by simply building an almost
  identical reply packet with the A bit set, and transmitting it on the
  PW ACH back to the source of the PW status message.

"can" is not an RFC 2119 word, so I am unclear what an implementation is
supposed to do. There is no perceptable benefit for sending an ack as
far as I can see since there is no described behavior if an ack is not
received.

Furthermore, in Section 5.3 we have a statement that under some
circumstances an Ack MUST be sent.

---

Section 5.5

  Currently the only PW status codes which MAY be sent using the S-PE
  bypass procedure are:

That is not a "MAY"! You are trying to "Other status codes except for
those listed MUST NOT be sent using the S-PE bypass procedure"

---

Section 5.5

It seems to me that the S-PE bypass mode has a race condition that
causes a quirk. The final sentence of 5.5 says...

  However the same PW Status TLVs MUST
  also be sent in LDP to keep the S-PEs state updated.

The implication here is that a fault (say x2) is raised and sent by both
mechanisms. The fault clears rapidly and the fault clear is sent by both
mechanisms. Because of speed of delivery, the egress T-PE will see the
fault raised and cleared twice.

I need to be convinced that this does not matter.

---

Section 5.5.1

  When a PW Segment along an MS-PW is using the LDP control protocol, a
  flag bit MUST be set in the interface parameters sub-TLV to indicate
  that the T-PE is requesting S-PE bypass status message mode.

Surely you don't mean this! Do you mean:

  When a PW Segment along an MS-PW is using the LDP control protocol
  wishes to request use of the S-PE bypass status message mode, it sets
  the B bit in the interface parameters sub-TLV as shown in Figure 3.

I think you need an IANA registry for the flags in the interface
parameters sub-TLV.

Oh, and please label Figure 3 correctly! The caption is also wrong.

---

Seciton 7 is inadequate. The referenced documents do not describe the
security of the ACH. While I believe this has been documented elsewhere,
you need to give a correct reference.

[Ballot comment]
These would probably all get fixed by the RFC editor, but I noticed them so I included them here.

1) Header should be:

  Updates: 5585 (if approved)

2) There's a "MUST not" in s5.3 - is that supposed to be "MUST NOT"?

3) Expiry date in status of memo section doesn't match the date in the header.

[Ballot comment]
- section 2: s/two Provider Edge (PE)/two Provider Edge (PE)
devices/?

- section 2: s/and [REDUNDANCY].../and elsewhere [REDUNDANCY]/

- 5.3 1st para: if an unknown or malformed TLV is received but
in a message containing >1 TLV, does that imply anything about
the other TLVs in that message?

IANA has questions about the IANA Actions specified in this document.

IANA understands that, upon approval of this document, there are three
IANA Actions which must be completed.

First, in the Pseudowire Associated Channel Types registry in the
Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Value: [tbd1]
Description: PW OAM Message
TLV Follows: [see question below]
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value of 0x0022 for this assignment.

IANA Question: should the field in this registration for "TLV Follows"
be set to "No" ?

Second, in the Pseudowire Switching Point PE Sub-TLV Type registry in
the Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Type: [tbd2]
Length: [see question below]
Description: Static PW/MPLS-TP PW segment ID of last PW segment traversed
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 0x07 for this
registration.

IANA Question: what should the "Length" field be set to in this
registration?

Third, in the Pseudowire Interface Parameters Sub-TLV type Registry
registry in the Pseudowire Name Spaces (PWE3) registry located at:

http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml

a new registration will be added as follows:

Parameter: [tbd3]
ID Length: [see question below]
Description: Generic Protocol Flags
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 0x16 for this
assignment, however this value has already been assigned to another
protocol use.

IANA Question: what should the "ID Length" field be set to in this
registration?

IANA understands that these are the only actions that need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Pseudowire Status for Static Pseudowires) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Pseudowire Status for Static Pseudowires'
  as a 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 2011-10-05. 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 specifies a mechanism to signal Pseudowire (PW) status
  messages using an PW associated channel (ACh). Such a mechanism is
  suitable for use where no PW dynamic control plane exits, known as
  static PWs, or where a Terminating Provider Edge (T-PE) needs to send
  a PW status message directly to a far end T-PE. The mechanism allows
  PW OAM message mapping and PW redundancy to operate on static PWs.
  This document also updates rfc5885 in the case when BFD is used to
  convey PW status signaling information.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/


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

Document Writeup for draft-ietf-pwe3-static-pw-status-06.txt

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Andy Malis

Yes, I have reviewed this revision and believe it is ready for
publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, it has been well reviewed and received good last-call
comments. In addition, it has received a lot of discussion through its
iterations on the pwe3 email list.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No, no concerns or issues. I noticed at least one typo, such
as a space before a comma. This can be corrected by the RFC Editor. No
IPR has been filed.

(1.e) 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 for the document.

(1.f) 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
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes, it passes id-nits.

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are split. There are two normative references
that are still working group drafts. We expect these drafts to be
completing soon.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section requests the allocation of
three new codepoints in existing registries that belong to the working
group.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A

(1.k) 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 specifies a mechanism to signal Pseudowire (PW) status
messages using an PW associated channel (ACh). Such a mechanism is
suitable for use where no PW dynamic control plane exits, known as
static PWs, or where a Terminating Provider Edge (T-PE) needs to send
a PW status message directly to a far end T-PE. The mechanism allows
PW OAM message mapping and PW redundancy to operate on static PWs.

This document is a product of the PWE3 working group.

This document is STANDARDS TRACK.

Working Group Summary
This document represents the consensus of the working group.
It is a part of the MPLS-TP project in the IETF.

Document Quality
It is required for the use of pseudowires for statically
provisioned MPLS-TP, and thus is expected to be widely implemented and
deployed. There are no concerns regarding the document's quality.

Personnel
Who is the Document Shepherd for this document?
Andy Malis

Who is the Responsible Area Director?
Stewart Bryant