Pseudowire Redundancy
draft-ietf-pwe3-redundancy-09

[Ballot discuss]
Thanks for the section 4.2.  Operational Requirements, but I believe that you miss the monitoring part.
Only configuration is mentioned at
  o  (T-)PEs participating in PW redundancy MUST support the
      configuration of revertive or non-revertive protection switching
      modes if both modes are supported.

Please add a bullet point about the monitoring of the protection switching mode, along with the configuration.
Always imagine the situation of two NMS changing the configuration....

[Ballot comment]
I've been confused by the section 3.2.1 title "Single Multi-Homed CE".
When I looked at the first sentence in that section, "The following figure illustrates an application of single segment pseudowire redundancy", I thought: ok, "single" in the title means SS-PW. The figure 2 was in line with that assumption.
Following the same logic, "3.2.2. Multiple Multi-Homed CEs" was targeting MS-PW.
However, the figure 3 was not representing MS-PW

Ok, I got now, thanks to Stewart Bryant's explanation, but my point remains: please change the 3.2.* section titles to something more meaningful.
For example:
    [Single-Homed | dual-Homed]  CE With [ MS-PW  SS-PW] Redundancy

Note: I always start reading a document by analyzing the table of content!

Along the same lines, section 3.2 is only for SS-PW, right? So be consistent with the sentence from 3.2.1 "The following figure illustrates an application of single segment pseudowire redundancy.": either copy it or remove it (if you have the title right)

Part of the OPS-DIR review done by Nevil Brownlee, a few typos:

1. Intro:  "ensuring that only one active path ..." needs to end in
    something like "is active at any one time."

2. Terminology:  You need to be consistent in capitalising UP.
  You define "Up PW," but mostly refer to it as "UP PW."

s 1:    s/describes framework/describes a framework/

s 3.2.1  s/are not be propagated/are not propagated/

s.3.2.4  "one of the PE to forward the traffic and the
        other to standby status." seems odd.  How about
        "one of the PE to forward the traffic, while the
        other remains in standby status" ?

s 4.1    s/MUST besupported./MUST be supported./

s 4.2    empty bullet at end of list

[Ballot discuss]
Thanks for this document. It is quite readable and explains the
scenarios well.

Unfortunately, the document does not cover all possible scenarios and
it is hard to tell whether some key ones are left out on purpose (because
they are not needed), on purpose (because they are hard to solve), or by
mistake (but are still important). Maybe section 3.2 can help by
explaining whether the reference scenarios are examples or a closed set.

I have a specific case in mind that can be captured by the following
figure.


            |<-------------- Emulated Service ---------------->|
            |                                                  |
            |          |<------- Pseudo Wire ------>|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnels-->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+    AC  V
      +-----+    |    | PE1|==================|PE2 |    |    +-----+
      |    |----------|....|...PW1.(active)...|....|----------|    |
      |    |          |    |==================|    |          |    |
      | CE1 |          +----+                  +----+          | CE2 |
      |    |          +----+                  +----+          |    |
      |    |          |    |==================|    |          |    |
      |    |----------|....|...PW2.(standby)..|....|----------|    |
      +-----+    |    | PE3|==================|PE4 |    |    +-----+
                AC    +----+                  +----+    AC


In this figure, it is unclear to me whether coordination between the
active and standby PWs is possible without a "vertical" control
protocol. But I am also not sure whether this is needed given that the
PWs could be permanently provisioned and the switching could be
performed in the CEs based on service-level OAM.

But the answer to this question begs a big question about the solutions
proposed for a number of the other scenarios. The issue can be summed
up by asking: what is the difference between service-level protection
and PW protection?

Note that the figure is a developed case of figure 2, or a degenerate
case of figure 3.

---

There seem to be some unstated assumptions about how CEs detect and
act on failures. For example, in 3.2.1 it is not clear whether
both ACs from CE1 are intended to be sending traffic all the time
(so that the PEs make the switching choices) or whether CE1 is
expected to detect failure and switch over to the other AC.

For the reverse direction traffic, this is an interesting problem
because unless the CE is running continuity OAM in the active
emulated service, it may not know that it needs to start receiving
on the other AC.

But, if there is an assumption that ACs are live-live, or that the
emulated service runs OAM, then the PW protection requirements are
quite a bit simpler.

---

I think your references to RFC 4447 should often be to RFC 4446. For
example, in Section 2:

  o  Up PW: A PW which has been configured (label mapping exchanged
      between PEs) and is not in any of the PW defect states specified
      in [RFC4447].  Such a PW is is available for forwarding traffic.

But, maybe you would also want this to be future-proof. When *any* PW
fault is reported by the status code field, doesn't that make a Down PW?

---

The exclusion of 1+1 is, I suppose, OK if it has WG support. But the
presentation in Section 4.1 is a bit abrubpt: "you might be able to do
1+1 is you like, but it is out of scope."

Can you do two things:
- indicate that 1+1 is out of scope near the top of the document so
  that readers get the picture
- give some reason why it is out of scope

[Ballot comment]
There is quite a slection of unexplained acronyms that you should sort
out.

---

I don't think you should make such a big thing of the difference between
SS-PW and MS-PW protection. You are doing end-to-end PW protection and if
you call it that, you don't have to go through any hoops.

As a counterpoint to this, I don't think that you can claim that
protection mechanisms in the PSN necessarily provide everything that is
needed for SS-PW protection. Consider a PE that is homed to two
networks. It is likely that when switching from one network to another
we will switch to a separate PW in its own tunnel, rather than switch
the PW to a new tunnel. (Note also that the figure in my Discuss could
easliy apply to SS-PWs, and AC/PE protection would be wanted and not
available from the PSN.)

But the bottom line is to have a lighter touch wrt PSN protection
techniques. What you are defining here supplements those techniques. It
may be run instead of or as well as PSN techniques and (obviously) is
very useful when those techniques are not available.

You certainly should not be worried about creating multiple layers of
protection. This is normal, and an important part of network operation
is to decise which layers to enable, and how to prioritise between the
layers.

---

I do think it is a shame that you do not consider segment protection as
part of this work.

---

It is disappointing that this document describes the solution. Surely
you could make this document more abstract and leave the description of
the solution to draft-ietf-pwe3-redundancy-bit.

---

The terminology here seems to be very subtly different from that in
draft-ietf-pwe3-redundancy-bit. For example "Up PW" or "UP PW". It would
make sense to have just one terminology section between the two docs
(probably here), and avoid any ambiguity.

(Actually, there is some internal inconsistency in this I-D, as well.)

---

In Section 2

  o  Revertive protection switching: Traffic will be carried by the
      primary PW if it is UP and a wait-to-restore timer expires and the
      primary PW is made the active PW.

I think there is something missing. At least punctuation, but probably
words.

---

In section 2 there is a contradiction between the definition of Primary                           
PW:

      When the primary PW comes back up
      after a failure and qualifies for the active state, the PW
      endpoint always reverts to it.

And the existence of a definition for non-revertive switching.

---

By the way, did you look at RFC 4427?             
I find some of the terminology here a little loose and not in step with
normal usage for protection switching.

---

In Section 4.1 you have:

  o  Protection switchover can be initiated from a PE e.g. using a
      manual lockout/force switchover, or it may be triggered by a
      signal failure i.e. a defect in the PW or PSN.  Manual switchover
      may be necessary if it is required to disable one PW in a
      redundant set.  Both methods MUST be supported and signal failure
      triggers MUST be treated with a higher priority than any local or
      far-end manual trigger.

This is very unusual and I am surprised that the operators in the WG
have bought in to it. What it says is that if an operator takes a PW
out of service (using a lockout) or forces the traffic onto a particular
PW, then a network failure may override what the operator said. This
would be pretty bad news in an optical network (because you might blind
an engineer), but in a packet network it is only a problem because it
would be a surprise to the operator and might reuslt in a traffic hit.

---

In section 4.1 it seems you have a somewhat underspecified requirement.

  o  Note that a PE MAY be able to forward packets received from a PW
      with a standby status in order to avoid black holing of in-flight
      packets during switchover.  However, in the case of use of VPLS,
      all VPLS application packets received from standby PWs MUST be
      dropped, except for OAM packets.

Probably...
s/Note that a PE MAY be able to forward/A PE MAY forward/

But also, how long does it go on doing this for?
And in the VPLS case, what about control plane packets? Do you really
mean s/OAM/ACH/ ?

---

Please sort out "redundant set" vs. "redundancy set"

[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 comment]
Matthew, thank you: the -08 version is clear, and a pleasure to read.  It has fixed all my concerns about the language.  Good work.

[Ballot discuss]
There are numerous English errors that should be fixed before this gets to the RFC Editor.  They made this a bit hard to review, and are of the sort that will be hard for the RFC Editor to get right.  I'll mention in the comments the ones that caused me the most difficulty, and try to give my suggestions, but a good editing pass by a native English speaker who understands the technology better than I is in order.  I made this DISCUSS-level because I think failing to fix them will make it likely that key points in the document will be misunderstood, and because it has to be fixed before it's sent to the RFC Editor.

[Ballot comment]
-- Introduction --

  The objective of PW redundancy is to provide sparing of attachment
  circuits (ACs), Provider Edge nodes (PEs), and Pseudowires (PWs) to
  eliminate single points of failure, while ensuring that only one
  active path between a pair of Customer Edge nodes (CEs).

I can't parse this.  I don't know what "sparing of" means in this context, and the part that begins "while ensuring" isn't a complete clause.

-- Section 3 --

  The following sections describe show the reference architecture of
  the PE for PW redundancy and its usage in different topologies and
  applications.

Either "describe" or "show" needs to be removed.  And I think the sentence would read better as "and the usage of that architecture in different...."

-- Section 3.2.1 --

In the last sentence, remove "be" in "are not be propagated".

-- Section 3.2.2 --

  The following failure scenario illustrates the operation of PW
  redundancy in Figure 2.

Do you really mean figure 2, or do you mean figure 3, which is the figure in this section?

  After the change in status the algorithm
  for selection of PW needs to revaluate and select PW to forward
  traffic.

I'm not sure I understand what this is supposed to mean, but I'm going to try: is it, "the PW selection algorithm needs to re-evaluate, and select which PW to use to forward traffic." ?

  Furthermore, failures in the PSN are not be propagated to the
  attached CEs.

Extra "be" again.

  If the CEs do not perform native service protection switching, they
  may instead may use load balancing across the paths between the CEs.

Remove either "may" -- either one works.

-- Section 3.2.3 --

  The priority can be
  configuration or derivation from the PWid.

I don't understand this sentence.

  Lower the PWid higher the priority.

The phrasing is "The lower the PWid, the higher the priority," and it's only a sentence fragment.  I suspect that if you merge it with the previous sentence and re-word, all will be clear.  Maybe this?: "The priority can be configured or derived from the PWid (the lower the PWid, the higher the priority)."

-- Section 3.2.4 --

  illustrates the application of use of PW redundancy to
  Hierarchical VPLS

Is that "application of", or "use of", or "application and use of"?  Or something else?

  Whenever MTU-s performs a switchover, it needs to communicate to
  PE2-rs for the Standby PW group the change to the status of active.

I'm not sure what entity's status changes to active here.  I suggest rephrasing as "it needs to communicate [something] to [something]," because that ordering is likely to be clearer.  But when I try to rewrite it, I find that I don't understand it well enough as it's written to fix it.

-- Section 3.2.6 --

  In Figure 7, two provider access networks, each having two n-PEs,
  where the n-PEs are connected via a full mesh of PWs for a given VPLS
  instance.

This is not a complete sentence, and I can't figure out what it's trying to say.  It appears to be a subject with no verb.

  In this scenario, n-PEs can disseminate the status of PWs active/
  standby among them and furthermore to have it tied up with the
  redundancy mechanism such that per VPLS instance the status of
  active/backup n-PE gets reflected on the corresponding PWs emanating
  from that n-PE.

This sentence also needs serious untangling.

-- Section 4.1 --

      1+1 protection architecture MAY be
      suported, but its definition is for further study.

Typo, "supported".  Is it really its *definition* that needs further study?  Is that the right word here?

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 Redundancy) to Informational RFC





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

Edge WG (pwe3) to consider the following document:

- 'Pseudowire Redundancy'

  as an Informational RFC



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 framework comprised of a number of

  scenarios and associated requirements for pseudowire (PW) redundancy.

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

  in single segment PW applications, or between Terminating PE nodes in

  Multi-Segment 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 PW status is required to indicate the preferential

  forwarding status of active or standby for each PW in the redundancy

  set.











The file can be obtained via

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



IESG discussion can be tracked via

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





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

State changed to AD Evaluation::Revised ID Needed from Publication Requested.
A lot of minor editorial, so out of courtesy to other reviewers a quick clean up pass is in order.

(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 two lines that are two
long. The nit checker also seemed to mis-read the dates in the
document, they look good to me. Anyway, there's nothing that
wouldn't be caught by the RFC Editor anyway.

(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 references have already been
published. There are no downward references.

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

There are no IANA actions.

(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: TThis document describes a framework comprised of
a number of scenarios and associated requirements for pseudowire
(PW) redundancy. A set of redundant PWs is configured between
provider edge (PE) nodes in single segment PW applications, or
between Terminating PE nodes in Multi-Segment 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 PW status is required to
indicate the preferential forwarding status of active or standby for
each PW in the redundancy set.

This document is a product of the PWE3 working group.

This document is INFORMATIONAL.

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