Skip to main content

Explicit Path Routing for Dynamic Multi-Segment Pseudowires
draft-ietf-pwe3-mspw-er-06

Revision differences

Document history

Date Rev. By Action
2014-12-01
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-10-23
06 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-10-09
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-09-23
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-09-22
06 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-09-19
06 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-09-15
06 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-09-12
06 (System) RFC Editor state changed to EDIT
2014-09-12
06 (System) Announcement was received by RFC Editor
2014-09-11
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-09-11
06 (System) IANA Action state changed to In Progress
2014-09-11
06 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-09-11
06 Amy Vezza IESG has approved the document
2014-09-11
06 Amy Vezza Closed "Approve" ballot
2014-09-11
06 Adrian Farrel Ballot approval text was generated
2014-09-11
06 Adrian Farrel Ballot writeup was changed
2014-09-11
06 Adrian Farrel IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2014-09-10
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-09-10
06 Matthew Bocci IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-09-10
06 Matthew Bocci New version available: draft-ietf-pwe3-mspw-er-06.txt
2014-09-04
05 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2014-09-04
05 Ted Lemon
[Ballot comment]
In 3.2:
  The ER-TLV specifies the path to be taken by the MS-PW being
  established.  Each hop along the path is …
[Ballot comment]
In 3.2:
  The ER-TLV specifies the path to be taken by the MS-PW being
  established.  Each hop along the path is represented by an abstract
  node, which is a group of one or more S-PEs, identified by an IPv4,
  and IPv6 or an S-PE address.  The ER-TLV format is as per Section 4.1
  ^^^^^
  of [RFC3212].

I think the "and" that I indicated should be an "an".  I mention this because although it's a fairly obvious typo, it _could_ actually be intentional, and hence doesn't qualify as strictly editorial.  If it is intentional, you should remove the preceding comma.

In 4.1:
  3.  If a second ER Hop TV does exist, and the node is also a part of

Again kind of nit-picky, but I think you mean TLV here, not TV.

FWIW (referring to Stephen's comment), I did not find section 4 difficult to follow.
2014-09-04
05 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-09-04
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-09-03
05 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-09-03
05 Stephen Farrell
[Ballot comment]

- I'm not sure to what extent this may be a significant
threat, but want to check. This new mechanism seems to create …
[Ballot comment]

- I'm not sure to what extent this may be a significant
threat, but want to check. This new mechanism seems to create
a new way to attempt to DoS or probe a MS-PW if one is allowed
to send any traffic on that MS-PW as an S-PE (or a zombied
S-PE) - any such sender can nominate the path for traffic. Why
is that not a new security consideration? If it is, (and I
think it is), then at least noting that in the security
considerations section would seem right. And how might one
detect or otherwise mitigate such a nasty S-PE?

- To be honest, I found 4.1 and 4.2 very hard to take in. I'd
suggest maybe a re-write but IFF others have had similar
difficulty. (If its just me, then ignore me.) Some examples
below.

- 2nd sentence of 4.1 - who is selecting when? (Passive
voice?)

- "MUST attempt" is very odd, is that the same as "MAY not
bother"? :-)

- "If a loop free path cannot be found..." by whom?

- "If the L bit is not set in the first ER Hop and if the node
is not part of the abstract node described by the first ER Hop
(i.e it does not lie within the prefix as determined by the
prefix length specified in the ER-Hop TLV), it has received
the message in error, and MUST reply with a Label Release
Message with a "Bad Initial ER Hop Error" (0x04000004) status
code." Does that *all* really have to be one and only one
sentence?
2014-09-03
05 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-09-03
05 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-09-03
05 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-09-02
05 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-09-02
05 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-09-02
05 Alia Atlas [Ballot comment]
Ok - sorry for the confusion.
2014-09-02
05 Alia Atlas [Ballot Position Update] Position for Alia Atlas has been changed to No Objection from Discuss
2014-09-02
05 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-09-01
05 Alissa Cooper
[Ballot comment]
Wondering if any of the mays and musts in Section 4.2 should be MAYs or MUSTs. I noted that in 4.1, the text …
[Ballot comment]
Wondering if any of the mays and musts in Section 4.2 should be MAYs or MUSTs. I noted that in 4.1, the text says "Processing continues as per Section 4.2, where a new explicit route TLV MAY be added to the Label Mapping Message," but the behavior specified in 4.2 is not described normatively.
2014-09-01
05 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2014-08-29
05 Kathleen Moriarty [Ballot comment]
Looks ok from a security standpoint, interested to see the clearer language from Alia's review.
2014-08-29
05 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-08-29
05 Meral Shirazipour Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2014-08-28
05 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-08-28
05 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-08-28
05 Alia Atlas
[Ballot discuss]
This is hopefully straightforward.

In 1) of Sec 4.1 it says "If the L bit is set and the local node
    …
[Ballot discuss]
This is hopefully straightforward.

In 1) of Sec 4.1 it says "If the L bit is set and the local node
      is not part of the abstract node described by the first ER Hop,
      the node selects a next hop that is along the path to the
      abstract node described by the first ER Hop."
but then in 6) it is stated "Finally, the node replaces the first ER Hop with any ER Hop that
      denotes an abstract node containing the next hop.  This is
      necessary so that when the explicit route is received by the next
      hop, it will be accepted."

The behavior in 1) seems to contradict the concern in 6).  Basically, I don't see a reason
for (6) to happen and would like clearer reasoning.

I'm also concerned that (6) might cause a narrowing of the specified abstract node
so that the second ER Hop TLV's abstract node can't be reached.  For instance,
say the ER TLV is (10.0/16 , 10.2/16) and say that node 10.0.1.1 receives for 10.0/16
and then selects the route of 10.0.1.200 followed by 10.0.2.12, which has a neighbor of of 10.2.3.13.
Couldn't 10.0.1.1 send on (10.0.1/24, 10.2/16) which would then cause 10.0.2.12 to need to
either send an error if 10.0.1/24 was strict?

In Sec 4.2, it says "  Otherwise, if the node is a member of the abstract node for the first
  ER-Hop, then a series of ER Hops may be inserted before the First ER
  Hop or may replace the first ER Hop. Each ER Hop in this series must
  denote an abstract node that is a subset of the current abstract
  node."

Is this before or after the first ER Hop TLV is deleted as per 4) in Sec 4.1 ? 

Is the idea that the path should stay inside the first abstract node until the second
abstract node is topologically adjacent?  Unlike RSVP-TE, it seems like reaching a
node in the first ER Hop TLV's abstract node isn't enough to remove the ER Hop TLV?

It would really help with clarity if the desired functionality were described clearly as
well as the specific steps to take.  The specific steps given are pretty unclear as to
what conditions are break; and which are continue;
2014-08-28
05 Alia Atlas [Ballot Position Update] New position, Discuss, has been recorded for Alia Atlas
2014-08-25
05 Adrian Farrel
[Ballot comment]
Need to pick up the nits from Meral's GenArt review

> [Page 6], Section 4.1, typo: "A noted in Section 1"---->"As noted in …
[Ballot comment]
Need to pick up the nits from Meral's GenArt review

> [Page 6], Section 4.1, typo: "A noted in Section 1"---->"As noted in Section 1"
>
> [Page 6],"but each node MUST attempt to determine a loop-free path",
> if the only method to detect a loop is http://tools.ietf.org/html/rfc6073#section-7.6,
> then perhaps a reference to this RFC would be useful.
> [Page 8], Section 5, typo :"consesus"---->"consensus"
2014-08-25
05 Adrian Farrel Ballot comment text updated for Adrian Farrel
2014-08-25
05 Adrian Farrel
[Ballot comment]
Need to pick up the nits from Meral's GenArt review

> [Page 6], Section 4.1, typo: "A noted in Section 1"---->"As noted in …
[Ballot comment]
Need to pick up the nits from Meral's GenArt review

> [Page 6], Section 4.1, typo: "A noted in Section 1"---->"As noted in Section 1"
>
> [Page 6],"but each node MUST attempt to determine a loop-free path", if the
> only method to detect a loop is http://tools.ietf.org/html/rfc6073#section-7.6,
> then perhaps a reference to this RFC would be useful.
>
> [Page 8], Section 5, typo :"consesus"---->"consensus"
2014-08-25
05 Adrian Farrel Ballot comment text updated for Adrian Farrel
2014-08-25
05 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for Writeup
2014-08-25
05 Adrian Farrel Ballot has been issued
2014-08-25
05 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2014-08-25
05 Adrian Farrel Created "Approve" ballot
2014-08-25
05 Adrian Farrel Placed on agenda for telechat - 2014-09-04
2014-08-25
05 Adrian Farrel Changed consensus to Yes from Unknown
2014-08-22
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-08-21
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Hoffman.
2014-08-18
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jason Weil
2014-08-18
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jason Weil
2014-08-15
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2014-08-15
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Hoffman
2014-08-12
05 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-08-12
05 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pwe3-mspw-er-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pwe3-mspw-er-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

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

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

In the TLV Type Name Space subregistry of the Label Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces/

Value: [ TBD-by-IANA-at-registration ]
Description: L2 PW Address of Switching Point
Reference: [ RFC-to-be ]

IANA notes that the authors have requested that the value 0x0805 be used for this registration.

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

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

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.
2014-08-11
05 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-08-11
05 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-08-08
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-08-08
05 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Explicit Path Routing for Dynamic …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Explicit Path Routing for Dynamic Multi-Segment Pseudowires) to Proposed Standard

The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Explicit Path Routing for Dynamic Multi-Segment Pseudowires'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-22. 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

  Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit
  path may be required to provide a simple solution for 1:1 protection
  with diverse primary and backup MS-PWs for a service, or to enable
  controlled signaling (strict or loose) for special MS-PWs.  This
  document specifies the extensions and procedures required to enable
  dynamic MS-PWs to be established along explicit paths.

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

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


No IPR declarations have been submitted directly on this I-D.
2014-08-08
05 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-08-08
05 Adrian Farrel Last call was requested
2014-08-08
05 Adrian Farrel Ballot approval text was generated
2014-08-08
05 Adrian Farrel IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2014-08-08
05 Adrian Farrel Last call announcement was changed
2014-08-08
05 Adrian Farrel Last call announcement was generated
2014-08-08
05 Adrian Farrel Last call announcement was generated
2014-08-08
05 Adrian Farrel Ballot writeup was changed
2014-08-08
05 Adrian Farrel Ballot writeup was changed
2014-08-08
05 Adrian Farrel Ballot writeup was generated
2014-08-07
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-08-07
05 Matthew Bocci New version available: draft-ietf-pwe3-mspw-er-05.txt
2014-06-11
04 Adrian Farrel
AD review
=========
Authors,

Thanks for your work on this document. I have conducted my normal AD
review having received the publication request. The purpose …
AD review
=========
Authors,

Thanks for your work on this document. I have conducted my normal AD
review having received the publication request. The purpose of the
review is to find issues and concerns that improve the quality of the
document for readability and implementation, and to remove issues that
might otherwise get found during IETF last call, directorate reviews,
and IESG evaluation.

I think that in general this document is fine, but I think it needs some
work on clarity. Hopefully none of my points is contentious, and they
can all be handled through some fairly simple edits. of course, every
point is open for discussion and you can refute each and every one of
them.

I'll put the document into "Revised I-D Needed" state and wait to see an
update and/or email from you.

Thanks,
Adrian

===

On a copyright thing...
Are you sure that some of this material hadn't been lifted pretty much
unchanged from RFC 3212? You might at least acknowledge that in the
Acknowledgements section.

---

Section 1

  For 1:1 protection of MS-PWs with
  primary and backup paths, MS-PWs SHOULD be established through a
  diverse set of S-PEs (Switching Provider-Edge) nodes to avoid any
  single points of failure at PW level.

I think s/SHOULD be/need to be/
The points are:
- This is really not a case for RFC 2119 language
- "should" is not really good enough for proper 1:1 protection

---

Do you not think that the Introduction should discuss a little about how
the path might be known? Specifically how the head-end T-PE knows what
explicit route to use. It may be enough to say "In many deployments the
head-end T-PE will not have a view of the topology of S-PEs and so the
explicit route will need to be supplied from a management application.
How that management application determines the explicit route is outside
the scope of this document."

---

Section 1

  This draft proposes an additional mechanism

Don't say "draft" say "document" because you want this text in an RFC.
Don't "propose", "define" or "specify" because you want this in a
protocol specification.

---

Section 3.1 needs to discuss how uniqueness of "S-PE addresses" is
guaranteed/arranged.

I suggest you formally define the term "S-PE address"

What does "format similar to" actually mean?

---

Section 3.1

  If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned
  with an S-PE address, then on receiving a Dynamic MS-PW label mapping
  message the S-PE MUST return a label release with the "Resources
  Unavailable" ( 0x00000038)" status code.

It is not clear to me whether this is new normative behavior or a
restatement of draft-ietf-pwe3-dynamic-ms-pw. This isn't helped by the
fact that "Dynamic MS-PW label mapping message" seems to be a new term.

You should probably define the term explicitly somehow with reference to
what it contains that makes it such a message (not just an ordinary
label mapping message) and a reference to draft-ietf-pwe3-dynamic-ms-pw.

Then you need to help clarify if this is new behavior. If it is not,
then you can include "As described in [ref]..."  If it *is* new behavior
for an existing message you have to explain how this is backward
compatible with current processing of this message. If it is new
behavior for a *new* message (i.e. defined in this document) then the
text is very out of order and at the least you need some explanation of
where this message is defined and what it does.

---

Section 3 might usefully say some overview stuff like:
- An explicitly routed PW is set up using a Label Mapping message that
  carries an ordered list of the S-PEs through which the PW is expected
  to run.
- The ordered list is encoded as a series of ER Hop TLVs encoded in a
  ER TLV that is carried in the Label Mapping message.

Doing this would save the reader ploughing through section 3 trying to
work out what it is all about.

---

If the ER Hop TLV can contain an IP address identifying an abstract
node, why is it necessary for each S-PE to have a unique S-PE address
formed as an AII?

---

Section 3.2

    Length
          Specifies the length of the value field in bytes.

There is, of course, no "value" field, so you could be a little clearer.
Unfortunately, there is currently a theme in the IESG on multi-byte
integer fields that means you need to say how the integer is encoded on
the wire, so you need to add "encoded in line format".

BUT...

Wait a minute. You are re-using 0x0800 for the ER TLV. Good. We don't
need to define multiple TLVs for the same function. But why are you
writing this document as though you are defining the TLV? Why is there
no mention of RFC 3212?

The same questions apply to the ER Hop TLV and the two of its types
that you are re-using.

This wouldn't take a lot of text and would allow you to delete a fair
bit. Something along the lines of...

  The process defined in this document makes use of the ER TLV defined
  in [RFC3212].  This TLV can be placed in a Label Mapping message used
  for dynamic PW setup as described in Section 4. 
 
  The ER TLV contains one or more ER Hop TLVs, each describing a hop
  along the desired path or the PW.  The procedures described in this
  document allow for the use of the "IPv4 Prefix ER-Hop TLV" and the
  "IPv6 Prefix ER-Hop TLV" (both defined in [RFC3212]) and also the
  "L2 PW address of PW Switching Point" defined in this document.

---

Curiously, in 3.4.1 you have
    IP Address
          A four-byte field indicating the IP Address.
while in 3.4.2 you have
    IPv6 address
          A 128-bit unicast host addresses.
It makes one wonder.

This issue would disappear with the fix previously mentioned.

---

For both the IPv4 and IPv6 hops, I think you need to think about (and
document) whether you support less than fully specified IP addresses.
For both of the prefix lengths you appear to allow 1-n (n = 32 or 128)
yet for IPv6 you seem to say it is a unicast host address which would
preclude anything other than 128.

---

3.4.3 needs some work...

The section title says "ER-Hop 3: L2 PW Address" but while this may be
the third ER-Hop type you support in this usage, the hop type is
actually 5. I suggest you remove the numbers from all three subsection
titles.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |U|F|          0x0802          |      Length = 18              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The value you have used in 0x0805. But (of course) you should use
TBD1 and reflect that in the IANA section.


    |L|            Reserved                        |    PreLen    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  AII Type=02  |    Length    |        Global ID              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Having to fields called "Length" makes the documentation ambiguous.
Suggest you make the first one "TLV-Length"


    |      Global ID (contd.)      |        Prefix                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Prefix (contd.)        |        AC ID                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      AC ID                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    U/F
          These bits MUST be set to zero and the procedures of [RFC5036]
          followed when the TLV is not known to the receiving node.


    Type
          A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW
          Address, Type = 0x0805

    Length
          Specifies the length of the value field in bytes = 18.

    L Bit
          Set to indicate Loose hop.
          Cleared to indicate a strict hop.

    PreLen
          Prefix Length 1-96

It is slightly curious that RFC 5003 didn't find a need for indicating
the prefix length. Since it is (presumably!) your intention that the
count to 96 spans the Global ID, Prefix, and AC ID fields, I think you
need to make that clear here and describe its usage later. Otherwise
one would rationally assume that the prefix length applies to the prefix
field.

    L2 PW Address
          An AII Address as defined in [RFC5003].

Rather than say this (which is confusing because there is no such L2 PW
Address field) you should say "All other fields (AII Type, Length, Global
ID, Prefix, and AC ID) define the L2 PW Address and are to be set and
interpreted as defined in Section 3.2 of [RFC5003]."

---

4.1

  A PW Label Mapping Message containing an explicit route TLV MUST
  specify the next hop for a given MS-PW path. 

What do you mean "MUST"? Surely...

  A PW Label Mapping Message containing an Explicit Route TLV specifies
  the next hop for a given MS-PW path. 

---

4.1

  Selection of this next
  hop MAY involve a selection from a set of possible alternatives.

s/MAY/may/

---

4.1

  The mechanism
  used to select a particular path is also outside of the scope of this
  document, but each node MUST attempt to determine a loop-free path.
  Note that such mechanisms MAY be overridden by local policy.

This is ambiguous...

"MUST attempt" but if it can't find one it is OK to go ahead with a
loop?

Local policy may override attempting to find a loop-free path?

Local policy may override the mechanism to select a path (which is a
local policy on account of not being part of this document)?

What information does an S-PE have available to select path and
determine whether there is a loop?

What should an S-PE do if a path can't be selected without a loop?

---

4.1

  1.  The node receiving the Label Mapping Message must evaluate the
      first ER-Hop.

This one should be "MUST", but you also need to qualify with "...that
contains an ER TLV."

---

4.1

      If the L bit is set and the local node
      is not part of the abstract node described by the first ER-Hop,
      the node selects a next hop that is along the path to the
      abstract node described by the first ER-Hop.

And how will it make that determination?

---

4.1

      If there is no first
      ER-Hop, the message is also in error and the node should return a
      "Bad Explicit Routing TLV Error" (0x04000001) status code in a
      Label Release Message sent to upstream node.

I presume this means if there is an ER TLV that does not contain an ER
Hop TLV.

I presume it remains legal to have a Label Mapping message without an
ER TLV per point 2 of this section.

Perhaps you could clarify this.

---

Section 5

  This draft proposes one new TLV type:

  TLV Type                              Suggested Value  Reference
  ------------------------------------  ---------------  ---------
  L2 PW Address of Switching Point        0x0805          This Document

I think this needs to read...

  IANA is requested to assign a further code point from the IETF
  Consensus portion of this registry as follows:

  TLV Type                              Value  Reference
  ------------------------------------  ------- ---------
  L2 PW Address of Switching Point      TBD1    This Document

  A value of 0x0805 is requested.
2014-06-11
04 Adrian Farrel IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2014-06-05
04 Adrian Farrel
Document Writeup for Working Group Documents

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

Changes are expected …
Document Writeup for Working Group Documents

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

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

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

Proposed Standard. This document defines new protocol procedures and a new TLV.

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

Technical Summary:

  Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit
  path may be required to provide a simple solution for 1:1 protection
  with diverse primary and backup MS-PWs for a service, or to enable
  controlled signaling (strict or loose) for special MS-PWs.  This
  document specifies the extensions and procedures required to enable
  dynamic MS-PWs to be established along explicit paths.

Working Group Summary:

  The document has been held up in the working group for a while because it is
  dependent on draft-ietf-pwe3-dynamic-ms-pw, which is currently in the RFC Editor's
  queue (draft-ietf-pwe3-mspw-er was split out from that draft in 2011). We kept this
  draft in the WG until draft-ietf-pwe3-dynamic-ms-pw reached the RFC Editor in case
  any changes were made during WG LC, IETF LC, or IESG deliberation that might
  result in changes to this draft. As it turned out, no such changes were needed.

Document Quality:

  There is at least one publicly known, shipping implementation of this draft (ALU). The
  document text has been stable for quite some time, other than a few recent changes
  made as a result of the shepherd's review.

Personnel:

  Andrew Malis is the Document Shepherd
  Adrian Farrel is the Responsible Area Director

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

  I did a shepherd's review prior to IESG submission and found one small technical nit
  and a bunch of editing nits, which were all corrected in the revision being submitted.

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

  None. It's been in the WG for a while and had good discussion and comments.

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

  No.

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

  None.

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

  Yes.

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

  None have been filed.

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

  There is solid WG consensus behind this document.

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

  No.

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

  The document passes nits cleanly.

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

  N/A

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

  Yes.

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

  All are RFCs except for draft-ietf-pwe3-dynamic-ms-pw, which is in the RFC Editor's
  queue.

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

  No.

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

  No.

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

  The IANA considerations section is very simple, it requests one new entry to the TLV
  Type list at http://www.iana.org/assignments/ldp-namespaces/ldp-
  namespaces.xhtml#ldp-namespaces-4 , in the IETF Consensus range.

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

  None.

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

  N/A
2014-06-04
04 Adrian Farrel IESG state changed to AD Evaluation from Publication Requested
2014-06-03
04 Andy Malis
Document Writeup for Working Group Documents

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

Changes are expected …
Document Writeup for Working Group Documents

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

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

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

Proposed Standard. This document defines new protocol procedures and a new TLV.

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

Technical Summary:

  Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit
  path may be required to provide a simple solution for 1:1 protection
  with diverse primary and backup MS-PWs for a service, or to enable
  controlled signaling (strict or loose) for special MS-PWs.  This
  document specifies the extensions and procedures required to enable
  dynamic MS-PWs to be established along explicit paths.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The document has been held up in the working group for a while because it is dependent on draft-ietf-pwe3-dynamic-ms-pw, which is currently in the RFC Editor's queue (draft-ietf-pwe3-mspw-er was split out from that draft in 2011). We kept this draft in the WG until draft-ietf-pwe3-dynamic-ms-pw reached the RFC Editor in case any changes were made during WG LC, IETF LC, or IESG deliberation that might result in changes to this draft. As it turned out, no such changes were needed.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There is at least one publicly known, shipping implementation of this draft (ALU). The document text has been stable for quite some time, other than a few recent changes made as a result of the shepherd's review.

Personnel:

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

Andrew Malis, Adrian Farrel

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

I did a shepherd's review prior to IESG submission and found one small technical nit and a bunch of editing nits, which were all corrected in the revision being submitted.

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

None. It's been in the WG for a while and had good discussion and comments.

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

No.

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

None.

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

Yes.

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

None have been filed.

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

There is solid WG consensus behind this document.

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

No.

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

The document passes nits cleanly.

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

N/A

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

Yes.

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

All are RFCs except for draft-ietf-pwe3-dynamic-ms-pw, which is in the RFC Editor's queue.

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

No.

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

No.

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

The IANA considerations section is very simple, it requests one new entry to the TLV Type list at http://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xhtml#ldp-namespaces-4 , in the IETF Consensus range.

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

None.

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

N/A
2014-06-03
04 Andy Malis State Change Notice email list changed to pwe3-chairs@tools.ietf.org, draft-ietf-pwe3-mspw-er@tools.ietf.org
2014-06-03
04 Andy Malis Responsible AD changed to Adrian Farrel
2014-06-03
04 Andy Malis IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-06-03
04 Andy Malis IESG state changed to Publication Requested
2014-06-03
04 Andy Malis IESG process started in state Publication Requested
2014-06-03
04 Andy Malis Tag Waiting for Referenced Document set. Tag Other - see Comment Log cleared.
2014-06-03
04 Andy Malis IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2014-06-03
04 Andy Malis Intended Status changed to Proposed Standard from None
2014-06-03
04 Andy Malis Changed document writeup
2014-06-03
04 Andy Malis Document shepherd changed to Andrew G. Malis
2014-05-09
04 Matthew Bocci New version available: draft-ietf-pwe3-mspw-er-04.txt
2014-03-11
03 Matthew Bocci New version available: draft-ietf-pwe3-mspw-er-03.txt
2012-12-11
02 Matthew Bocci New version available: draft-ietf-pwe3-mspw-er-02.txt
2012-12-03
01 Andy Malis IETF state changed to Waiting for WG Chair Go-Ahead from WG Document
2012-12-03
01 Andy Malis Annotation tag Other - see Comment Log set.
2012-06-18
01 Andy Malis Passed WG last call on Oct. 6, awaiting a new revision of draft-ietf-pwe3-dynamic-ms-pw-15, then will be submitted to the IESG.
2012-06-18
01 Matthew Bocci New version available: draft-ietf-pwe3-mspw-er-01.txt
2011-09-22
00 (System) New version available: draft-ietf-pwe3-mspw-er-00.txt