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 |