Pseudowire Preferential Forwarding Status Bit
draft-ietf-pwe3-redundancy-bit-09

[Ballot comment]
Thank you with your patient work to address my Discuss.

---

I continue to be disappointed by the piecemeal invention of bolt-on
signaling features for PW management. It really seems that the working
group needs to work on a functional architecture for pseudowires to
work out all of the bits and pieces that are needed for redundancy,
bandwidth, multi-segment routing, etc., etc. I wish this would happen
before we incrementally munge the protocol too much, but I
understand that this is not directly actionable for the authors of this
document.

[Ballot discuss]
1.

In the section 10, you wrote:
  This document makes the following update to the PwOperStatusTC
  textual convention in RFC 5542 [9]:
You can't simply update a Textual Convention (TC) like this, but putting a new
TC, out of context. A TC belongs to a MIB module. You need a new revision of
that MIB module: RFC5542bis. Note: you could cut/paste the new revision of the
MIB module in this document, and obsolete RFC5542, but that would be misleading
from the document title. Also, having a new RFC5542bis will cause some
problems: there are many TCs in there, so surely, many references to RFC5542...
which in turn will need to be updated.

Now, looking more closely at your proposed change.
    - dormant(4):  The PW is not in a condition to pass
                      packets but is in a 'pending' state,
                      waiting for some external event. For example, the
                      PW Preferential Forwarding status state machine as
                      defined in [RFC XXXX (this document)] is in state
                      "STANDBY".

The only change that you require is the addition of "For example, the PW
Preferential Forwarding status state machine as defined in [RFC XXXX (this
document)] is in state "STANDBY" in dormant(4).

IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't
require the extra work to produce RFC5542bis. Indeed, you don't change the TC
semantic. What I believe you should be doing is: - a sentence such as (I trust
you on the exact wording): this document illustrates how the dormant value of
the PwOperStatusTC TC can be used to ..." and you include the meaning of your
initial extra sentence - you remove "update: RFC 5542"


Your proposed solution is:

    10. MIB Considerations
      New MIB objects for the support of PW redundancy will be defined in
      a separate document.

I don't understand why you went that route.
Dan and I gave you a solution in the text above.


2.

- Section 5.1 "independent mode".
What do you mean by "management indication" in:

  In steady state with consistent configuration, a PE will always find
  an active PW. However, it is possible that such a PW is not found due
  to a mis-configuration. In the event that an active PW is not found,
  a management indication SHOULD be generated. If a management
  indication for failure to find an active PW was generated and an
  active PW is subsequently found, a management indication SHOULD be
  generated, so clearing the previous failure indication. Additionally,
  a PE MAY use the optional request switchover procedures described in
  Section 6.3. to have both PE nodes switch to a common PW.

A syslog message, a SNMP notification, something else, or this is left
completely open... in other words: "please do a little bit of management to
please the OPS people ;-)"

Can you justify why you don't even mention "management indication" in the
second mode, i.e. section 5.2 "master/slave mode" note: I never seen the term
management "indication". Do you want to say "management notification"?


You have not replied to: Can you justify why you don't even mention "management indication" in the
second mode, i.e. section 5.2 "master/slave mode"?

3.

Here is another point, reported by Dan Romascanu, which I cut/pasted here:
I did not have the time for a full OPS-DIR review, but I had a look at
draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow.
Benoit entered a DISCUSS on a specific issue related to a proposed
modification of the PwOperStatusTC from RFC 5542, which I support, but I
think that the manageability problems with this I-D are broader. From an
operator perspective I believe that there needs to be clear indication
of the modes of operation (Independent, Master/Slave) besides the active
/ standby status of the PW, otherwise there will be no way to understand
the status and configuration in different network situations. This may
lead to changes to RFC 5542, but I think that mentioning just the MIB
changes is not sufficient, as implementing the MIB modules is not
mandatory for all PW devices, so the need to expose the modes and
forwarding states needs to operators needs to be made in a
protocol-independent manner.


Not sure what you have done to address this point.

[Ballot discuss]
.

In the section 10, you wrote:
  This document makes the following update to the PwOperStatusTC
  textual convention in RFC 5542 [9]:
You can't simply update a Textual Convention (TC) like this, but putting a new
TC, out of context. A TC belongs to a MIB module. You need a new revision of
that MIB module: RFC5542bis. Note: you could cut/paste the new revision of the
MIB module in this document, and obsolete RFC5542, but that would be misleading
from the document title. Also, having a new RFC5542bis will cause some
problems: there are many TCs in there, so surely, many references to RFC5542...
which in turn will need to be updated.

Now, looking more closely at your proposed change.
    - dormant(4):  The PW is not in a condition to pass
                      packets but is in a 'pending' state,
                      waiting for some external event. For example, the
                      PW Preferential Forwarding status state machine as
                      defined in [RFC XXXX (this document)] is in state
                      "STANDBY".

The only change that you require is the addition of "For example, the PW
Preferential Forwarding status state machine as defined in [RFC XXXX (this
document)] is in state "STANDBY" in dormant(4).

IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't
require the extra work to produce RFC5542bis. Indeed, you don't change the TC
semantic. What I believe you should be doing is: - a sentence such as (I trust
you on the exact wording): this document illustrates how the dormant value of
the PwOperStatusTC TC can be used to ..." and you include the meaning of your
initial extra sentence - you remove "update: RFC 5542"


Your proposed solution is:

    10. MIB Considerations
      New MIB objects for the support of PW redundancy will be defined in
      a separate document.

I don't understand why you went that route.
Dan and I gave you a solution in the text above.


2.

- Section 5.1 "independent mode".
What do you mean by "management indication" in:

  In steady state with consistent configuration, a PE will always find
  an active PW. However, it is possible that such a PW is not found due
  to a mis-configuration. In the event that an active PW is not found,
  a management indication SHOULD be generated. If a management
  indication for failure to find an active PW was generated and an
  active PW is subsequently found, a management indication SHOULD be
  generated, so clearing the previous failure indication. Additionally,
  a PE MAY use the optional request switchover procedures described in
  Section 6.3. to have both PE nodes switch to a common PW.

A syslog message, a SNMP notification, something else, or this is left
completely open... in other words: "please do a little bit of management to
please the OPS people ;-)"

Can you justify why you don't even mention "management indication" in the
second mode, i.e. section 5.2 "master/slave mode" note: I never seen the term
management "indication". Do you want to say "management notification"?


You have not replied to: Can you justify why you don't even mention "management indication" in the
second mode, i.e. section 5.2 "master/slave mode"?

3.

Here is another point, reported by Dan Romascanu, which I cut/pasted here:
I did not have the time for a full OPS-DIR review, but I had a look at
draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow.
Benoit entered a DISCUSS on a specific issue related to a proposed
modification of the PwOperStatusTC from RFC 5542, which I support, but I
think that the manageability problems with this I-D are broader. From an
operator perspective I believe that there needs to be clear indication
of the modes of operation (Independent, Master/Slave) besides the active
/ standby status of the PW, otherwise there will be no way to understand
the status and configuration in different network situations. This may
lead to changes to RFC 5542, but I think that mentioning just the MIB
changes is not sufficient, as implementing the MIB modules is not
mandatory for all PW devices, so the need to expose the modes and
forwarding states needs to operators needs to be made in a
protocol-independent manner.


Not sure what you have done to address this point.

[Ballot comment]
-
Section 5.1

  1. For FEC128 PW, the PW with the lowest pw-id value is selected.

  2. For FEC129 PW, each PW in a redundant set is uniquely identified

No idea what FEC128 and FEC129 were.
I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8,
where by the way, they're spelled "FEC 128" and "FEC 129". So please add a
reference.


You solve the issue in section 5.1 by removing FEC128 and FEC129, but FEC 128 and FEC 129 still appear in different places of the document

[Ballot discuss]
[Thanks to the authors for there work on this draft. They have handled a
lot of my Discuss and Comment and we have made a lot of progress.

I have made updates, deleted points thathave been addressed, and used #
to indicate new text.

---

Section 5.2.

  Note that the behavior
  described in this section assumes correct configuration of the Master
  and Slave endpoints. This document does not define a mechanism to
  detect errors in the configuration.

I suggest this is broken. You should at least be able to detect the
error (not necessary to be able to resolve it) and report it. Also to
not get into an unresolvable protocol breakdown when there are two T-PEs
that think they are Masters.

Actually, requirements 2 and 3 of Section 4.2 of draft-ietf-pwe3-
redundancy seem to speak against this text.

# In your response via email you said:
# > In this case, the management system can detect the mis-configuration
# > and raise an alarm.
#
# Frankly, if the mamangement system could detect the misconfiguration
# it would not have allowed it in the first place. You need to consider
# CLI configuration of remote PEs by different operators at different
# times, and clearly it is quite possible for both PEs to be given the
# same role.
#
# You continue...
# > I do not think a mis-configuration will resolve in a protocol
# > breakdown. If say the slave PE-rs node in Figure 15-6 operates as a
# > Master, then traffic will flow towards the MTU which will drop it.
#
# What you appear to be saying is that in some cases of misconfiguration
# data will simply fail to flow. This would presumably be detected by
# the user and would result in te operator running diagnostics and
# looking at coniguration details. butit seems to me that in other cases
# the initial state might coincdentally be fine even with two Masters
# because they happen to agree. However, after a failure, the two
# Masters might take different decisions resulting in no recovery even
# though the consumer had been led to believe that there was adequate
# protection in place.
#
# If you are determined to not detect and report such misconfiguration,
# I think you should enhance the quoted text to read:
# 
#  Note that the behavior
#  described in this section assumes correct configuration of the Master
#  and Slave endpoints. This document does not define a mechanism to
#  detect errors in the configuration, and misconfiguration might lead
#  to protection switchover failing to work correctly.

---

Section 7.1

  When a PE enters the AC receive (or transmit) defect state for a PW,
  it MUST send a forward (reverse) defect indication to the remote
  peers over all PWs in the redundancy set when required by the PW type
  in [8] .

I think this is subtly incorrect. It applies only to PWs in the
redundancy set that terminate at the PE and that are connected to the
AC.

# I believe the case you are missing here is that there are PWs in the
# redundant set that do not terminate at this PE. It is impossible for
# the PE that enters the AC receive (or transmit) defect state for a PW
# to send (or cause to be sent) a defect indication over PWs that are
# not local. See Figure 15-2 for an example: When PE1 enters the AC
# receive defect state for PW1, it cannot cause a defect indication to
# be sent on PW2. Similarly PE2 (entering the receive or transmit defect
# state for PW1) will not be able to send a defect indication on PW2.
# Nevertheless, PW2 is in the redundant set.
#
# What is more, I don't think you want indications sent on PW2 in this
# situation.
#
# Furthermore, consider when there are two ACs from CE1 to PE1. AC1
# connects to PW1, and AC2 connects to PW2. The AC/PW pairs provide
# protection and so the PWs are in a redundant set. When PE1 detects
# an error on AC1 and enters AC receive defect state for PW1, I don't
# think you want it to transmit a defect indication on PW2.

---

Section 8

  A PE implementation compliant to RFC 4447 [2], and which does not
  support the generation or processing of the 'Preferential Forwarding'
  status bit or of the 'request switchover' status bit, will ignore
  these status bits if they are received from a peer PE.

I struggled to find this behavior defined in RFC 4447. While I believe
that many implementations might take this approach, I also think many
might view the text in 4447 that indicates that the bits represent
"faults" to mean that even unknown status code bits should be
interpreted as PW failures. (Hence my burbling earlier about flipping
the sense of the bits.)

If you can point me at the text in 4447, I will back off this issue.

# In discussion of this point via email you suggested:
# 1. RFC 4447 never intended its rules to apply to future bit settings
# 2. RFC 5036 has an overriding definintion of "status"
#
# But 5036 (which is only a cleaned up version of 3036) does not deal
# with the PW status concept since it exists purely for MPLS signaling.
# Furthermore, the status codes in 5036 represent LDP protocol events
# and statuses and are encoded as one-shot integers. Indeed, it is only
# when the LDP Status TLV status code is set to 0x00000028, "PW status"
# (a status code not even listed in RFC 5036), that the PW status code
# defined in RFC 4447 is used. So I think that 5036 is a side-track for
# this discussion.
#
# That brings us back to RFC 4447 where we have in Section 5.4.2:
#
#  Each bit in the status code field can be set individually to indicate
#  more than a single failure at once.  Each fault can be cleared by
#  sending an appropriate Notification message in which the respective
#  bit is cleared.  The presence of the lowest bit (PW Not Forwarding)
#  acts only as a generic failure indication when there is a link-down
#  event for which none of the other bits apply.
#
# It is obviously your contention that this text is not quite what was
# intended because:
# a. you think the field can be used to convey status as well as failure
#    conditions
# b. you think the field can be used to carry instructions as well as
#    failure conditions and statuses
# c. you think that the rules about carrying multiple bits can vary
#    depending on what bits are set
# d. you think that a receiver that does not understand a set bit MUST
#    ignore that bit.
#
# I can live with all or any of these rules, but I insist they are new
# rules. They must be stated clearly and they must be stated as an
# update to RFC 4447.

---

On re-reading Section 5.2 I cannot work out what happens if the Master
node is the PE that fails. It looks like this is not covered and would
provide a problem.

# You responded via email that in the case the Master fails nothing can
# work because the T-LDP session is down.
#
# Now let's try to clear this up...
#
# In Section 5.2 you have
#  One endpoint node of the redundant set of PWs is designated the
#  Master and is responsible for selecting which PW both endpoints must
#  use to forward user traffic.
# So there is exactly one Master for a redundant set.
# But in some scenarios, for example, that in Figure 15-2, there are
# plenty of options. Are you saying that if, in this figure, PE1 is
# designated the Master, and if PE1 fails, it will be impossible to
# send data via PE2? I don't believe this is your intent.

[Ballot comment]
I continue to be disappointed by the piecemeal invention of bolt-on
signaling features for PW management. It really seems that the working
group needs to work on a functional architecture for pseudowires to
work out all of the bits and pieces that are needed for redundancy,
bandwidth, multi-segment routing, etc., etc. I wish this would happen
before we incrementally munge the protocol too much, but I
understand that this is not directly actionable for the authors of this
document.

---

Section 5.2

  One endpoint node of the redundant set of PWs is designated the
  Master and is responsible for selecting which PW both endpoints must
  use to forward user traffic.

I think...
s/must//

# The word "MUST" is redundant.

---

Section 10

# Does anyone really intend to produce a new MIB module?

---

# The volume of change seems substantial. Is the WG OK with these
# changes?

---

# Need to run id-nits again and tidy up the document.

---

# Section 2 bullet c
# Stray additional period.

[Ballot discuss]
1.
In the section 10, you wrote:
  This document makes the following update to the PwOperStatusTC
  textual convention in RFC 5542 [9]:
You can't simply update a Textual Convention (TC) like this, but putting a new TC, out of context.
A TC belongs to a MIB module. You need a new revision of that MIB module: RFC5542bis.
Note: you could cut/paste the new revision of the MIB module in this document, and obsolete RFC5542, but that would be misleading from the document title.
Also, having a new RFC5542bis will cause some problems: there are many TCs in there, so surely, many references to RFC5542... which in turn will need to be updated.

Now, looking more closely at your proposed change.
    - dormant(4):  The PW is not in a condition to pass
                      packets but is in a 'pending' state,
                      waiting for some external event. For example, the
                      PW Preferential Forwarding status state machine as defined in [RFC
                      XXXX (this document)] is in state "STANDBY".

The only change that you require is the addition of "For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY" in dormant(4).

IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't require the extra work to produce RFC5542bis. Indeed, you don't change the TC semantic.
What I believe you should be doing is:
- a sentence such as (I trust you on the exact wording): this document illustrates how the dormant value of the PwOperStatusTC TC can be used to ..." and you include the meaning of your initial extra sentence
- you remove "update: RFC 5542"

2.
- Section 5.1 "independent mode".
What do you mean by "management indication" in:

  In steady state with consistent configuration, a PE will always find
  an active PW. However, it is possible that such a PW is not found due
  to a mis-configuration. In the event that an active PW is not found,
  a management indication SHOULD be generated. If a management
  indication for failure to find an active PW was generated and an
  active PW is subsequently found, a management indication SHOULD be
  generated, so clearing the previous failure indication. Additionally,
  a PE MAY use the optional request switchover procedures described in
  Section 6.3. to have both PE nodes switch to a common PW.

A syslog message, a SNMP notification, something else, or this is left completely open... in other words:
"please do a little bit of management to please the OPS people ;-)"

Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode"
note: I never seen the term management "indication". Do you want to say "management notification"?

3.
Here is another point, reported by Dan Romascanu, which I cut/pasted here:
I did not have the time for a full OPS-DIR review, but I had a look at
draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow.
Benoit entered a DISCUSS on a specific issue related to a proposed
modification of the PwOperStatusTC from RFC 5542, which I support, but I
think that the manageability problems with this I-D are broader. From an
operator perspective I believe that there needs to be clear indication
of the modes of operation (Independent, Master/Slave) besides the active
/ standby status of the PW, otherwise there will be no way to understand
the status and configuration in different network situations. This may
lead to changes to RFC 5542, but I think that mentioning just the MIB
changes is not sufficient, as implementing the MIB modules is not
mandatory for all PW devices, so the need to expose the modes and
forwarding states needs to operators needs to be made in a
protocol-independent manner.

[Ballot comment]

  Please consider the issues raised in the Gen-ART Review by
  Miguel Garcia on 23-May-2012.  I tend to agree with his points on
  RFC 2119 language in Sections 5 and 15.  Please find the review at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07447.html.

[Ballot discuss]
[Discuss updated 5/23 to cross-reference the requirements document for non-reversion and detection of misconfiguration, and to make observations about the failure of a Master in master/slave mode.]

I have a long and rather rambling Discuss on this document. I think
that it is important to address the requirements of management and
control of end-to-end service protection as provided by PWs, so I am
in no way rejecting the concept of this document. On the other hand, I
found quite a number of issues that caused me concern. I have split
these across this Discuss (where I hope changes to the text, or
conversations in email, will resolve the issues) and Comments where I
am less bothered by how or whether you address the issues.

---

Section 1

  In order to support AC or spoke PW redundancy, at least one of the
  PEs on which a PW terminates MUST be different from that on which the
  primary PW terminates, as described in [6].

This is not true, is it? Well, it may be true that the reference says
this, but in that case the reference is wrong.

AC redundancy can be provided using a pair of parallel ACs between the
same CE and PE pair (although this seems to be explicitly excluded by
figure 4-1). What you are describing is PE protection.

I think some of the confusion here is because of the terminology
inconsistency. RFC 3985 is quite clear that the AC does not form part
of the PW. So, this document is all about protecting the emulated
service.

This does appear to be noticed earlier in the section where it says:
       
  Scenarios, such as those above, therefore rely on a set of two or
  more pseudowires to protect a given VPWS or VPLS.

I believe that the document should be clear up front that two protection
mechanisms are being described in this document. The first is end-to-end
service protection (where AC and T-PE failure are protected) and end-to-
end PW protection (where the working and protection PWs run between the
same pair of T-PEs). The document also needs to note clearly that PW
segment protection (i.e. working and protection [multi-] segment
protection between a pair of S-PEs) is out of scope.

>> Ah, I found this in the last paragraph of Section 2. A bit lost in
  the morass of other text.

Note that an excellent way to handle this discuss will be the wholesale
deletion of text and replacement with a simple reference to [6].

---

Looks to me that [6] is used normatively.

---

It is not clear to me why you don't support 1+1 protection. But section
2 clearly rules it out.

  In the absence of faults, all PWs are UP both locally and remotely
  and a PE node needs to select a single PW to forward user packets to.
  This is referred to as the active PW. All other PWs will be in
  standby and MUST NOT be used to forward user packets. 

Perhaps this restriction should be stated. Or is there the possibility
that a future protocol extension will be made to add 1+1 support?

---

Section 2

  In order for both ends of the service to select the same PW for
  forwarding user packets, this document defines a new status bit, the
  'Preferential Forwarding' status bit, to allow a PE node to indicate
  the preferential forwarding state of a PW to its peer PE node. 

I may have missed something here, but in 1:1 end-to-end *service*
protection, the choice of which PW to use has to be made at the CE not
the T-PE. But the signaling (LDP) is between PEs. How does the CE learn
the settings of the status code bits?

---

I think there is some confusion about when bits are set and cleared in
the status code. Some of this is textual.

Section 11.1 has...                                                           

  0x00000020 When the bit is set, it indicates "PW forwarding 
              standby". 

              When the bit is cleared, it indicates "PW forwarding 
              active".

Which is good and means that the text should probably refer to this as
the "PW forwarding standby bit" rather than "PW Preferential Forwarding"
as currently in section 6. (Note that IANA will need a name for the bit
in the registry - they seem to have dug the names out of section 6, but
this should be explicit in the IANA section of the document).

Then the bit used for requesting switchover gives me a problem. While I
understand the issues (selection from a pool that may be larger than 1,
need to synchronize, etc.), the explanation of the status code field in
RFC 4447 is clear that setting a bit represents a "fault". Thus, it
would be reasonable to handle a set bit as "cannot send traffic on this
PW" whereas you are asking for it to mean "please send traffic on this
PW". (Again, IANA will need a name for this bit in the registry.)

I do wonder whether, given the existence of OAM and fault status bits,
and the definition of precedence, you need this bit. It even seems to
allow conflict with the precedence.

---

What happens when a T-PE that supports this I-D sends a switchover
request to a T-PE that foes not support this I-D? Presumably it will
register the request as a fault (as above) and will not send traffic.

---

In section 2

      a. A MANDATORY 1:1 PW protection with a single active PW and one
        standby PW. An active PW can forward data traffic and control
        plane traffic, such as Operations, Administration, and
        Maintenance (OAM) packets. A standby PW does not carry data
        traffic.

This does not say whether OAM packets and be carried on a standby PW.
Later, in section 3, I find:

  Standby PW: An UP PW that is not used for forwarding user traffic,
          but MAY forward OAM and specific control plane traffic.

And so on (e.g. Section 6.1)

  When a PW is in Standby state, the PEs MUST NOT forward user packets
  over the PW but MAY forward PW OAM packets and specific control plane
  packets.

Perhaps, rather than listing types of message, you should note that all
ACH packets are allowed.

---

Section 2

          b. Multi-homing of a PE node to two or more PE nodes. 

What does this mean? A PE is multi-homed to multiple PEs? I suppose you
are trying to talk about parallel PWs between two T-PEs, and a PE that
is at the far end of a relationship with a CE that is multi-homed to
more than one T-PE?

---

Section 3

          The designation of Primary is performed by local
          configuration for the PW at the PE and is only required when
          revertive behavior is used. 

But all of the text (for example, in 5.1 and 5.2) uses MUST for
reversion, so there appears to be no option.

Which is odd because the second requiremen of Section 4.1 of draft-ietf-pwe3-redundancy says that non-revertive behavior MUST be supported.

---

Section 5

I think that you need to clarify which mode of operation would be used
in the case of figure 15-2. I think that master/slave mode cannot be
used, and that independent mode only works with configuration. There is
a degenerate case of this topology where there is absolutely no LDP
communication between the PEs on the active PW and those on the standby
PW.

---

Section 5.1 first point 2

"we propose"

please restate this protocol specification in terms of absolute
statements of required behavior.

---

Section 5.2.

  Note that the behavior
  described in this section assumes correct configuration of the Master
  and Slave endpoints. This document does not define a mechanism to
  detect errors in the configuration.

I suggest this is broken. You should at least be able to detect the
error (not necessary to be able to resolve it) and report it. Also to
not get into an unresolvable protocol breakdown when there are two T-PEs
that think they are Masters.

Actually, requirements 2 and 3 of Section 4.2 of draft-ietf-pwe3-redundancy seem to speak against this text.

---

The timers need to have recommended defaults, and should be called out
as configurable.

---

Section 7

[5] is used normatively.

[8] is used normatively.

---

Section 7

  The procedures for determining and mapping PW and AC states MUST
  follow the rules in [8] with the following modifications. 

Does that mean this document updates [8]?

---

Section 7.1

  When a PE enters the AC receive (or transmit) defect state for a PW,
  it MUST send a forward (reverse) defect indication to the remote
  peers over all PWs in the redundancy set when required by the PW type
  in [8] .

I think this is subtly incorrect. It applies only to PWs in the
redundancy set that terminate at the PE and that are connected to the
AC.

---

Section 8

  A PE implementation compliant to RFC 4447 [2], and which does not
  support the generation or processing of the 'Preferential Forwarding'
  status bit or of the 'request switchover' status bit, will ignore
  these status bits if they are received from a peer PE.

I struggled to find this behavior defined in RFC 4447. While I believe
that many implementations might take this approach, I also think many
might view the text in 4447 that indicates that the bits represent
"faults" to mean that even unknown status code bits should be
interpreted as PW failures. (Hence my burbling earlier about flipping
the sense of the bits.)

If you can point me at the text in 4447, I will back off this issue.

---

Section 9

I don't think this section should be so banal.
You are introducing a feature that allows the compromise of signaling
for one PW between one pair of PEs, to change the behavior (disruptively)
on a PW between another pair of PEs. That seems to be a new and
interesting attack vector.

Therefore, you should at least flag this point and note that security on
a redundant set is only as good as the weakest security on any member
of that group.

---

On re-reading Section 5.2 I cannot work out what happens if the Master
node is the PE that fails. It looks like this is not covered and would
provide a problem.

[Ballot discuss]
I have a long and rather rambling Discuss on this document. I think
that it is important to address the requirements of management and
control of end-to-end service protection as provided by PWs, so I am
in no way rejecting the concept of this document. On the other hand, I
found quite a number of issues that caused me concern. I have split
these across this Discuss (where I hope changes to the text, or
conversations in email, will resolve the issues) and Comments where I
am less bothered by how or whether you address the issues.

---

Section 1

  In order to support AC or spoke PW redundancy, at least one of the
  PEs on which a PW terminates MUST be different from that on which the
  primary PW terminates, as described in [6].

This is not true, is it? Well, it may be true that the reference says
this, but in that case the reference is wrong.

AC redundancy can be provided using a pair of parallel ACs between the
same CE and PE pair (although this seems to be explicitly excluded by
figure 4-1). What you are describing is PE protection.

I think some of the confusion here is because of the terminology
inconsistency. RFC 3985 is quite clear that the AC does not form part
of the PW. So, this document is all about protecting the emulated
service.

This does appear to be noticed earlier in the section where it says:
       
  Scenarios, such as those above, therefore rely on a set of two or
  more pseudowires to protect a given VPWS or VPLS.

I believe that the document should be clear up front that two protection
mechanisms are being described in this document. The first is end-to-end
service protection (where AC and T-PE failure are protected) and end-to-
end PW protection (where the working and protection PWs run between the
same pair of T-PEs). The document also needs to note clearly that PW
segment protection (i.e. working and protection [multi-] segment
protection between a pair of S-PEs) is out of scope.

>> Ah, I found this in the last paragraph of Section 2. A bit lost in
  the morass of other text.

Note that an excellent way to handle this discuss will be the wholesale
deletion of text and replacement with a simple reference to [6].

---

Looks to me that [6] is used normatively.

---

It is not clear to me why you don't support 1+1 protection. But section
2 clearly rules it out.

  In the absence of faults, all PWs are UP both locally and remotely
  and a PE node needs to select a single PW to forward user packets to.
  This is referred to as the active PW. All other PWs will be in
  standby and MUST NOT be used to forward user packets. 

Perhaps this restriction should be stated. Or is there the possibility
that a future protocol extension will be made to add 1+1 support?

---

Section 2

  In order for both ends of the service to select the same PW for
  forwarding user packets, this document defines a new status bit, the
  'Preferential Forwarding' status bit, to allow a PE node to indicate
  the preferential forwarding state of a PW to its peer PE node. 

I may have missed something here, but in 1:1 end-to-end *service*
protection, the choice of which PW to use has to be made at the CE not
the T-PE. But the signaling (LDP) is between PEs. How does the CE learn
the settings of the status code bits?

---

I think there is some confusion about when bits are set and cleared in
the status code. Some of this is textual.

Section 11.1 has...                                                           

  0x00000020 When the bit is set, it indicates "PW forwarding 
              standby". 

              When the bit is cleared, it indicates "PW forwarding 
              active".

Which is good and means that the text should probably refer to this as
the "PW forwarding standby bit" rather than "PW Preferential Forwarding"
as currently in section 6. (Note that IANA will need a name for the bit
in the registry - they seem to have dug the names out of section 6, but
this should be explicit in the IANA section of the document).

Then the bit used for requesting switchover gives me a problem. While I
understand the issues (selection from a pool that may be larger than 1,
need to synchronize, etc.), the explanation of the status code field in
RFC 4447 is clear that setting a bit represents a "fault". Thus, it
would be reasonable to handle a set bit as "cannot send traffic on this
PW" whereas you are asking for it to mean "please send traffic on this
PW". (Again, IANA will need a name for this bit in the registry.)

I do wonder whether, given the existence of OAM and fault status bits,
and the definition of precedence, you need this bit. It even seems to
allow conflict with the precedence.

---

What happens when a T-PE that supports this I-D sends a switchover
request to a T-PE that foes not support this I-D? Presumably it will
register the request as a fault (as above) and will not send traffic.

---

In section 2

      a. A MANDATORY 1:1 PW protection with a single active PW and one
        standby PW. An active PW can forward data traffic and control
        plane traffic, such as Operations, Administration, and
        Maintenance (OAM) packets. A standby PW does not carry data
        traffic.

This does not say whether OAM packets and be carried on a standby PW.
Later, in section 3, I find:

  Standby PW: An UP PW that is not used for forwarding user traffic,
          but MAY forward OAM and specific control plane traffic.

And so on (e.g. Section 6.1)

  When a PW is in Standby state, the PEs MUST NOT forward user packets
  over the PW but MAY forward PW OAM packets and specific control plane
  packets.

Perhaps, rather than listing types of message, you should note that all
ACH packets are allowed.

---

Section 2

          b. Multi-homing of a PE node to two or more PE nodes. 

What does this mean? A PE is multi-homed to multiple PEs? I suppose you
are trying to talk about parallel PWs between two T-PEs, and a PE that
is at the far end of a relationship with a CE that is multi-homed to
more than one T-PE?

---

Section 3

          The designation of Primary is performed by local
          configuration for the PW at the PE and is only required when
          revertive behavior is used. 

But all of the text (for example, in 5.1 and 5.2) uses MUST for
reversion, so there appears to be no option.

---

Section 5

I think that you need to clarify which mode of operation would be used
in the case of figure 15-2. I think that master/slave mode cannot be
used, and that independent mode only works with configuration. There is
a degenerate case of this topology where there is absolutely no LDP
communication between the PEs on the active PW and those on the standby
PW.

---

Section 5.1 first point 2

"we propose"

please restate this protocol specification in terms of absolute
statements of required behavior.

---

Section 5.2.

  Note that the behavior
  described in this section assumes correct configuration of the Master
  and Slave endpoints. This document does not define a mechanism to
  detect errors in the configuration.

I suggest this is broken. You should at least be able to detect the
error (not necessary to be able to resolve it) and report it. Also to
not get into an unresolvable protocol breakdown when there are two T-PEs
that think they are Masters.

---

The timers need to have recommended defaults, and should be called out
as configurable.

---

Section 7

[5] is used normatively.

[8] is used normatively.

---

Section 7

  The procedures for determining and mapping PW and AC states MUST
  follow the rules in [8] with the following modifications. 

Does that mean this document updates [8]?

---

Section 7.1

  When a PE enters the AC receive (or transmit) defect state for a PW,
  it MUST send a forward (reverse) defect indication to the remote
  peers over all PWs in the redundancy set when required by the PW type
  in [8] .

I think this is subtly incorrect. It applies only to PWs in the
redundancy set that terminate at the PE and that are connected to the
AC.

---

Section 8

  A PE implementation compliant to RFC 4447 [2], and which does not
  support the generation or processing of the 'Preferential Forwarding'
  status bit or of the 'request switchover' status bit, will ignore
  these status bits if they are received from a peer PE.

I struggled to find this behavior defined in RFC 4447. While I believe
that many implementations might take this approach, I also think many
might view the text in 4447 that indicates that the bits represent
"faults" to mean that even unknown status code bits should be
interpreted as PW failures. (Hence my burbling earlier about flipping
the sense of the bits.)

If you can point me at the text in 4447, I will back off this issue.

---

Section 9

I don't think this section should be so banal.
You are introducing a feature that allows the compromise of signaling
for one PW between one pair of PEs, to change the behavior (disruptively)
on a PW between another pair of PEs. That seems to be a new and
interesting attack vector.

Therefore, you should at least flag this point and note that security on
a redundant set is only as good as the weakest security on any member
of that group.

[Ballot comment]
In case anyone is hunting, I can find just 4 out of the 12 authors
confirming on the PWE3 list that they are not aware of any IPR
disclosures that need to be made.

---

I continue to be disappointed by the piecemeal invention of bolt-on
signaling features for PW management. It really seems that the working
group needs to work on a functional architecture for pseudowires to
work out all of the bits and pieces that are needed for redundancy,
bandwidth, multi-segment routing, etc., etc. I wish this would happen
before we incrementally munge the protocol too much, but I
understand that this is not directly actionable for the authors of this
document.
                                     
---

You need to remove the citation from the Abstract.

---

The document was pretty hard to review because there are repetitions
and overlap between sections. Do you need all the text?

---

Please clean up "redundant set" or "redundancy set"

---

There's a lot of terminology in the Introduction that need clarifying.
I found...

SS-PW
PW
MS-PW
T-PE
PE-rs
PE
PWE3

---

Section 1
  Only one of these
  pseudowires is used by the PEs to forward user traffic on at any
  given time.

delete "on"

---

Figure 1-1
s/Pseudowire/Pseudowires/

---

Please decide "pseudowire" or "pseudo wire".
Cf. RFC 3985 figure 2 and draft-ietf-pwe3-redundancy figure 2

---

Section 1

  In
  this case, multiple MS-PWs are configured between a pair of T-PE
  nodes, as described in Figure 2 of [6].

Figure 2 of [6] would appear to be identical to figure 1-1. Why do
you reference it?

---

Section 1

  This document specifies a new PW status bit to indicate the
  preferential forwarding status of the PW for the purpose of notifying
  the remote PE of the preferential forwarding state of each PW in the
  redundancy set i.e. Active or Standby.

Please say "remote T-PE".

---

Section 2

  The PWE3 control protocol [2] defines the following status codes in
  the PW status TLV to indicate the state for an AC and a PW:

  0x00000000 - Pseudowire forwarding (clear all failures)

  0x00000001 - Pseudowire Not Forwarding

  0x00000002 - Local Attachment Circuit (ingress) Receive Fault

  0x00000004 - Local Attachment Circuit (egress) Transmit Fault

  0x00000008 - Local PSN-facing PW (ingress) Receive Fault

  0x00000010 - Local PSN-facing PW (egress) Transmit Fault

Firstly, I think these values are defined in RFC 4446 not RFC 4447.
Then, I think there is actually no need to list the values here.
You could, if you like, point to the registry.

But reading this section, I am not sure that this quoted text is
pertinent.

---

Section 2                   

You have put some terms in upper case that are not from RFC 2119.
Anyway, I am not convinced that RFC 2119 usage is helpful in this
early and descriptive section. Lowercase would be just fine.

---

Figure 4-1 caption
s/Architecure/Architecture/

---

Section 2 point d.

s/qualify/qualifies/

---

Section 3

I think you could prune this section quite heavily. For example, it is
probably not necessary to define a pseudowire or a PE.

---

Section 5.1

      The PW which corresponds to the
      minimum of the compared values across all PWs in the redundant is
      selected.

s/redundant/redundant set/  ?

---

Section 5.2

  One endpoint node of the redundant set of PWs is designated the
  Master and is responsible for selecting which PW both endpoints MUST
  use to forward user traffic.

I think...
s/MUST//

---

Section 7.2

  A PE enters the PW receive (or transmit) defect state for a PW
  service when one or more of the conditions specified in Section 8.2.1
  (Section 8.2.2) in [8] are met for all PWs in the redundancy set.

For the avoidance of doubt, I think you should
  s/for all/for each of the/

(It is not necessary that the same defect state should exist on each PW)

---

Section 10

I completely support Benoit's Discuss on this section. You cannot revise
a MIB module like this.

However, it really looks like you don't want to make a revision at all.
Changing one Description clause by adding "for example" is really not
worth the effort.

Why don't you just write an applicability note saying how the TC is used
to support the function described in this I-D?

---

Author's Addresses

s/Author's/Authors'/

[Ballot comment]
Note these comments are the same for both draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit.

Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft-ietf-pwe3-redundancy-bit.  Can't you just point from on to the other?

This uses the TCP MD5 "signature" option [RFC5036].  KARP's hopefully going to get this fixed sooner rather than later.  So there's nothing for the authors to do about this otherwise recurring gripe.

I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark:

1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036?
2nd - I think there's only one of them?
3rd - I think you mean control plane not control protocol?

How about the following tweaks to the security considerations section:

  This document uses the TCP MD5 Signature option, as specified
  in [2],  to protect pseudowires.  This document has the same
  security considerations as in the PWE3 control-plane [2].

If you want to future proof the text more maybe:

  LDP extensions/options that protect pseudowires must be
  implemented because the security considerations for the
  bits defined in this document have the same security
  considerations as the PWE3 control-plane [2].

[Ballot discuss]
1.
In the section 10, you wrote:
  This document makes the following update to the PwOperStatusTC
  textual convention in RFC 5542 [9]:
You can't simply update a Textual Convention (TC) like this, but putting a new TC, out of context.
A TC belongs to a MIB module. You need a new revision of that MIB module: RFC5542bis.
Note: you could cut/paste the new revision of the MIB module in this document, and obsolete RFC5542, but that would be misleading from the document title.
Also, having a new RFC5542bis will cause some problems: there are many TCs in there, so surely, many references to RFC5542... which in turn will need to be updated.

Now, looking more closely at your proposed change.
    - dormant(4):  The PW is not in a condition to pass
                      packets but is in a 'pending' state,
                      waiting for some external event. For example, the
                      PW Preferential Forwarding status state machine as defined in [RFC
                      XXXX (this document)] is in state "STANDBY".

The only change that you require is the addition of "For example, the PW Preferential Forwarding status state machine as defined in [RFC XXXX (this document)] is in state "STANDBY" in dormant(4).

IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't require the extra work to produce RFC5542bis. Indeed, you don't change the TC semantic.
What I believe you should be doing is:
- a sentence such as (I trust you on the exact wording): this document illustrates how the dormant value of the PwOperStatusTC TC can be used to ..." and you include the meaning of your initial extra sentence
- you remove "update: RFC 5542"

2.
- Section 5.1 "independent mode".
What do you mean by "management indication" in:

  In steady state with consistent configuration, a PE will always find
  an active PW. However, it is possible that such a PW is not found due
  to a mis-configuration. In the event that an active PW is not found,
  a management indication SHOULD be generated. If a management
  indication for failure to find an active PW was generated and an
  active PW is subsequently found, a management indication SHOULD be
  generated, so clearing the previous failure indication. Additionally,
  a PE MAY use the optional request switchover procedures described in
  Section 6.3. to have both PE nodes switch to a common PW.

A syslog message, a SNMP notification, something else, or this is left completely open... in other words:
"please do a little bit of management to please the OPS people ;-)"

Can you justify why you don't even mention "management indication" in the second mode, i.e. section 5.2 "master/slave mode"
note: I never seen the term management "indication". Do you want to say "management notification"?

[Ballot comment]
- Section 12 "Major Contributing Authors"
Not sure if it's a good idea to have this new section title.
Knowing how sensitive this authors/contributors topic is, I wouldn't like to see a precedent with this future RFC ,i.e.  "I see a Major Contributing Authors, so can we have Minor Contributing Authors section now?" So I would prefer "contributors" and "authors" sections.

- Section 5.1

  1. For FEC128 PW, the PW with the lowest pw-id value is selected.

  2. For FEC129 PW, each PW in a redundant set is uniquely identified

No idea what FEC128 and FEC129 were.
I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8, where by the way, they're spelled "FEC 128" and "FEC 129".
So please add a reference.

[Ballot comment]
Section 2:

MANDATORY
OPTIONAL
OPTIONALLY

Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized words in this section are a new magical usage of which I am unaware. Perhaps you might like to define terms?

5.1

  The PW endpoints MAY also implement the following optional active PW
  selection mechanism. 

  1. If the PW endpoint is configured with the precedence parameter on
      each PW in the redundant set, it MUST select the PW with the
      lowest configured precedence value. 

So you MAY do something that you MUST do? I am confused.

  a management indication SHOULD be generated

I may not understand what is meant by a "management indication" here, but it sounds like an implementation choice, not something that is required for interoperation. Did I get that wrong?

[Ballot comment]
The security considerations say that this is the same as for
4447, which is arguably correct, but 4447 really defers to
3036, which a) doesn't consider switching over to a "less good"
PW as a potential DoS (is it?) and b) only has TCP-MD5 based
security which even in 2001 attracted an IESG note, repeated in
3036 from rfc 2385 (from 1998!).  Any chance of getting some
21st century security stuff done in PW-land? (Sorry, but that's
hard to resist:-) This is probably not the place to fix that,
but it'd be good to know if there's a plan. Is there?

Nits:

- PE-rs is used without expansion (on p2)

- FEC128 and FEC129 are used without definition on p11
(As as AGI::SAII:TAII)

- What is the "system IP address"? (on p11) Could be fairly
obvious, but then again if a node has many addresses,
maybe not.

[Ballot comment]
Please check the idnits:

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 19 instances of too long lines in the document, the longest
    one being 4 characters in excess of 72.

  == The 'Updates: ' line in the draft header should list only the _numbers_
    of the RFCs which will be updated by this document (if approved); it
    should not include the word 'RFC' in the list.

  -- The draft header indicates that this document updates RFC5542, but the
    abstract doesn't seem to directly say this.  It does mention RFC5542
    though, so this could be OK.

Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
    first submitted before 10 November 2008.  Should you add the disclaimer?
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.) -- however,
    there's a paragraph with a matching beginning. Boilerplate error?

    IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
    "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.
      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."

    ... text found in draft:
    "Code Components extracted from this document must include Simplified BSD
......^
      License text as described in Section 4.e of the Trust Legal
      Provisions and are provided without warranty as described in the
      Simplified BSD License."


  -- The document date (May 1, 2012) is 20 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-08) exists of
    draft-ietf-pwe3-redundancy-07

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

In the Pseudowire Status Codes Registry in Pseudowire Name Spaces (PWE3)
registry located at:

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

the following, new registrations will be added:

Bitmask: 0x00000020
Description: PW Preferential Forwarding
Reference: [ RFC-to-be ]

Bitmask: 0x00000040
Description: PW Request Switchover
Reference: [ RFC-to-be ]

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 Preferential Forwarding Status Bit) to Proposed Standard





The IESG has received a request from the Pseudowire Emulation Edge to

Edge WG (pwe3) to consider the following document:

- 'Pseudowire Preferential Forwarding Status Bit'

  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-03-21. 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 a mechanism for standby status signaling of

  redundant pseudowires (PWs) between their termination points. A set

  of redundant PWs is configured between provider edge (PE) nodes in

  single-segment pseudowire (SS-PW) applications, or between

  terminating provider edge (T-PE) nodes in multi-segment pseudowire

  (MS-PW) applications.



  In order for the PE/T-PE nodes to indicate the preferred PW to use

  for forwarding PW packets to one another, a new status bit is needed

  to indicate a preferential forwarding status of Active or Standby for

  each PW in a redundant set.



  In addition, a second status bit is defined to allow peer PE nodes to

  coordinate a switchover operation of the PW.













The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/





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

(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 a lot of discussion
through its iterations. There are no concerns regarding reviews.

(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 concerns or issues. 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?

There were a couple of minor nits, such as eight lines that are too
long. There's nothing that wouldn't be caught by the RFC Editor.

(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. All of the normative references have
already been published. There are no downward references. There are
two informative references that are still drafts. One of these has
already been submitted to the IETF, and the other is an L2VPN WG
draft that is well in progress (it was just updated to -05 on Oct.
31).

(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?

IANA is asked to allocate two new status codes in an existing
registry, Pseudowire Status Codes Registry.

(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 describes a mechanism for standby
status signaling of redundant pseudowires (PWs) between their
termination points. A set of redundant PWs is configured between
provider edge (PE) nodes in single-segment pseudowire (SS-PW)
applications, or between terminating provider edge (T-PE) nodes in
multi-segment pseudowire (MS-PW) applications. In order for the
PE/T-PE nodes to indicate the preferred PW to use for forwarding PW
packets to one another, a new status bit is used to indicate a
preferential forwarding status of Active or Standby for each PW in a
redundant set. In addition, a second status bit is used to allow
peer PE nodes to coordinate a switchover operation of the PW.

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.

Document Quality: 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