Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
RFC 6391
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
07 | (System) | Received changes through RFC Editor sync (changed abstract to 'Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable … Received changes through RFC Editor sync (changed abstract to 'Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]') |
|
2015-10-14
|
07 | (System) | Notify list changed from pwe3-chairs@ietf.org, draft-ietf-pwe3-fat-pw@ietf.org to (None) |
|
2011-11-01
|
07 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-11-01
|
07 | (System) | RFC published |
|
2011-09-07
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-09-07
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2011-09-06
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-08-30
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-08-29
|
07 | (System) | IANA Action state changed to In Progress |
|
2011-08-29
|
07 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2011-08-29
|
07 | Cindy Morgan | IESG has approved the document |
|
2011-08-29
|
07 | Cindy Morgan | Closed "Approve" ballot |
|
2011-08-29
|
07 | Cindy Morgan | Approval announcement text regenerated |
|
2011-08-25
|
07 | Cindy Morgan | Removed from agenda for telechat |
|
2011-08-25
|
07 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation. |
|
2011-08-25
|
07 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
|
2011-08-25
|
07 | Adrian Farrel | Approval announcement text changed |
|
2011-08-25
|
07 | Adrian Farrel | Approval announcement text regenerated |
|
2011-08-25
|
07 | Adrian Farrel | Approval announcement text changed |
|
2011-08-25
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-25
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-24
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-23
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-23
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-23
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-23
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-22
|
07 | Pete Resnick | [Ballot comment] I fully support David's first DISCUSSion point. The shepherding report and the document writeup are pretty content free. - The IPR discussion was … [Ballot comment] I fully support David's first DISCUSSion point. The shepherding report and the document writeup are pretty content free. - The IPR discussion was missed. - I understand that the shepherding writeup was done before the assorted evaluations after -05, but it should have been updated to reflect. I have no objection to the document on technical grounds (it is well outside my area of expertise), but I also have no way to evaluate it on process grounds. |
|
2011-08-22
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-22
|
07 | Stephen Farrell | [Ballot comment] I don't get the meaning of the text below in section 12. Are yet more changes expected? "The congestion considerations applicable to … [Ballot comment] I don't get the meaning of the text below in section 12. Are yet more changes expected? "The congestion considerations applicable to PWs as described in [RFC3985] and any additional congestion considerations developed at the time of publication apply to this design." |
|
2011-08-22
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-22
|
07 | David Harrington | [Ballot comment] 1) in 8.5, incomplete sentence at the end. 2)in 1.2, "A similar design for general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label], Section … [Ballot comment] 1) in 8.5, incomplete sentence at the end. 2)in 1.2, "A similar design for general MPLS use has also been proposed [I-D.kompella-mpls-entropy-label], Section 9. " It would be good if there was a touch of analysis to accompany this statement. Are the two approaches able to co-exist? If the gerenal solution is approved, will this pwe-specific approach still be needed? (this is apparently provided in section 9. eirther eliminate the reference in 1.1, or provide a forward reference to section 9. 3) a reference for the TC bits (previously known as the EXP bits)? |
|
2011-08-22
|
07 | David Harrington | [Ballot discuss] Overall, thsi document is in good shape. A few adjustments would clarify the requirements of the proposal. 1) the shepherding document section 1.d … [Ballot discuss] Overall, thsi document is in good shape. A few adjustments would clarify the requirements of the proposal. 1) the shepherding document section 1.d does not include discussion of IPR: "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 specific concerns." 2) in 1.2, "Note that this may be a departure from considerations that apply to the general MPLS case. " It would be helpful to identify where the general case is defined, and to state whether this is or is not a departure, and what impact such departure might have. 3) in 2, "it is required that the NSP in the ingress PE identify flows" and in 3 "If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label." Is this an RFC2119 REQUIRED? how does this REQUIRED/MUST language correlate with the OPTIONAL status of this feature? Are the REQUIRED/MUST only applicable to implementations that support this specification? 4) in 5, "the default behaviour is not to include the flow label." should this be a MUST NOT? |
|
2011-08-22
|
07 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-08-22
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-22
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-22
|
07 | Dan Romascanu | [Ballot comment] 1. OAM is not expanded in any place. I think that the dedicated section should mention that the interpretation of the acronyms is … [Ballot comment] 1. OAM is not expanded in any place. I think that the dedicated section should mention that the interpretation of the acronyms is conformant to RFC 6291. 2. The text in the IANA specifications is slightly mis-leading as there is no amending of the IANA registry, just a change of reference when the RFC is published. I trust IANA knows what to do, but I think a better text would be something like: 'IANA is requested to reserve the PW Interface Parameters Sub-TLV type Registry value 0x17 for the Flow Label indicator with the reference column refering to this RFC.' |
|
2011-08-22
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-21
|
07 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-08-19
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-04
|
07 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-08-04
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-08-04
|
07 | Adrian Farrel | Placed on agenda for telechat - 2011-08-25 |
|
2011-08-03
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-08-02
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-07-19
|
07 | Amy Vezza | Last call sent |
|
2011-07-19
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <pwe3@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-pwe3-fat-pw-07.txt> (Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network) to Proposed Standard The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' <draft-ietf-pwe3-fat-pw-07.txt> as a Proposed Standard This is a second last call. The last call is only necessary because of a further late-received IPR disclosure The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-03. 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 Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1595/ |
|
2011-07-19
|
07 | Amy Vezza | Last Call was requested |
|
2011-07-19
|
07 | Amy Vezza | State changed to Last Call Requested from Waiting for AD Go-Ahead::External Party. |
|
2011-07-19
|
07 | Amy Vezza | Last Call text changed |
|
2011-07-19
|
07 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::External Party from IESG Evaluation.<br>Waiting for IPR issue to be resolved |
|
2011-07-19
|
07 | Adrian Farrel | Removed from agenda for telechat |
|
2011-07-19
|
(System) | Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-pwe3-fat-pw-07 | |
|
2011-07-18
|
07 | Stewart Bryant | [Ballot Position Update] New position, Recuse, has been recorded |
|
2011-07-17
|
07 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup. |
|
2011-07-17
|
07 | Adrian Farrel | Placed on agenda for telechat - 2011-08-11 |
|
2011-07-17
|
07 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
|
2011-07-17
|
07 | Adrian Farrel | Ballot has been issued |
|
2011-07-17
|
07 | Adrian Farrel | Created "Approve" ballot |
|
2011-07-06
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-07-06
|
07 | (System) | New version available: draft-ietf-pwe3-fat-pw-07.txt |
|
2011-06-01
|
07 | Rolf Winter | Request for Last Call review by TSVDIR Completed. Reviewer: Rolf Winter. |
|
2011-05-20
|
07 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead. |
|
2011-05-20
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-05-19
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Yaron Sheffer. |
|
2011-05-18
|
07 | David Harrington | Request for Last Call review by TSVDIR is assigned to Rolf Winter |
|
2011-05-18
|
07 | David Harrington | Request for Last Call review by TSVDIR is assigned to Rolf Winter |
|
2011-05-18
|
07 | David Harrington | Request for Last Call review by TSVDIR is assigned to Rolf Winter |
|
2011-05-18
|
07 | David Harrington | Request for Last Call review by TSVDIR is assigned to Rolf Winter |
|
2011-05-18
|
07 | Amanda Baber | Upon approval of this document, IANA understands that there is a single IANA Action that needs to be completed. In the Pseudowire Interface Parameters Sub-TLV … Upon approval of this document, IANA understands that there is a single IANA Action that needs to be completed. In the Pseudowire Interface Parameters Sub-TLV type Registry in the Pseudowire Name Spaces (PWE3) registry located at: http://www.iana.org/assignments/pwe3-parameters/pwe3-parameters.xml#pwe3-parameters-3 IANA will change the PW Interface Parameters Sub-TLV type Registry value 0x17 (Flow Label indicator) to refer to [ RFC-to-be ] instead of the current Internet Draft. IANA understands that this is the only IANA Action required upon approval of this document. |
|
2011-05-07
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
|
2011-05-07
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
|
2011-05-06
|
07 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <pwe3@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-pwe3-fat-pw-06.txt> (Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network) to Proposed Standard The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' <draft-ietf-pwe3-fat-pw-06.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-20. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/ No IPR declarations have been submitted directly on this I-D. Abstract Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on MPLS label stacks and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. |
|
2011-05-06
|
07 | Adrian Farrel | Last Call was requested |
|
2011-05-06
|
07 | (System) | Ballot writeup text was added |
|
2011-05-06
|
07 | (System) | Last call text was added |
|
2011-05-06
|
07 | (System) | Ballot approval text was added |
|
2011-05-06
|
07 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::AD Followup. |
|
2011-05-06
|
07 | Adrian Farrel | Last Call text changed |
|
2011-05-06
|
07 | Adrian Farrel | Ballot writeup text changed |
|
2011-05-06
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-05-06
|
06 | (System) | New version available: draft-ietf-pwe3-fat-pw-06.txt |
|
2011-01-29
|
07 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review === Hi, I have performed an AD review of your draft. Don't panic! I … State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review === Hi, I have performed an AD review of your draft. Don't panic! I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details. I am responsible for this I-D because Stewart Bryant is a co-author and therefore cannot take responsibility for the document. Your document describes a very small piece of function, and so there is very little of technical substance to discuss. As such, I was a bit surprised at the length and weight of this draft and I feel that it could usefully be heavily pruned. However, I doubt that there is energy or enthusiasm for that work, so I think you will just want to limit yourself to addressing my issues below. Most of my comments are pretty trivial: they are concerned with clarity and consistency of your text. But there are quite a lot of them, so I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion. Of course, all of my issues are up for discussion. Thanks for the work, Adrian --- I found the use of language a little relaxed. You use the same word, "label", to refer to a label value and to an entry in the shim header. It would probably be helpful to use the term "label" to refer to the label itself, and "label entry" to indicate the label, TC bits, and TTL. --- It seems to me that the description of what can be in the additional label entry is conflicted. On receipt of the pseudowire packet at the egress PE (which knows this additional label is present) the flow label is discarded without processing. This means that the label will not be used for any purpose in the packet processing except in the DPI of ECMP hashing. The flow label can never become the top label in normal operation That is, you will never pop a label to discover the flow label except at the egress where it is expected and ignored. Note that the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032], but is otherwise unconstrained by the protocol. And why is that restriction required given the two previous points? The flow label can never become the top label in normal operation, and hence the TTL in the flow label is never used to determine whether the packet should be discarded due to TTL expiry. Therefore there are no lower restrictions on the TTL value. Why do you call out "lower"? How about saying "there are no restrictions" The use of the TC bits (formerly known as the EXP bits) in the flow label is outside the scope of this document. Unless otherwise agreed by the ingress and egress PEs these bits MUST be set to zero by the ingress PE and MUST be ignored by the egress PE. "Out of scope" seems to be different from the subsequent statement about how he TC field must be treated. I am also not clear why the TTL discussion is different from the TC discussion. --- Document title: please spell out PSN --- Abstract: yuck! :-O Suggestion... OLD Where the payload carried over a pseudowire carries a number of identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on label stacks and use this to balance flows over ECMPs. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack. NEW Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on MPLS label stacks and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. END --- Try to avoid "ECMP paths" (or ECMPP as we call them ;-) --- Section 1 para 1 the use of ECMP paths for is known to be beneficial (and not harmful) to the operation of the PW. ?? --- Throughout... The plural of "pseudowire" is "pseudowires", not "pseudowire's". You may safely use "PWs" in your document. You have a number of other plurals formed as apostrophe-s. Please search for "'s" and fix as necessary. --- Section 1 Some pseudowires are used to transport large volumes of IP traffic between routers at two locations. I assume that, for some definition of "location" this is also true for routers at the same location. So how about... Some pseudowires are used to transport large volumes of IP traffic between routers. --- Section 1 Such pseudowire's do not require strict ordering to be preserved between packets of the pseudowire. They only require ordering to be preserved within the context of each individual transported IP flow. I see where this is going, but the first sentence is massively more relaxed than the second! How about turning it around... Such pseudowires only require packet ordering to be preserved within the context of each individual transported IP flow. They do not require packet ordering to be preserved between all packets of the across all IP flows within the pseudowire. --- Section 1 Some operators have requested the ability to explicitly configure such a pseudowire to leverage the availability of multiple ECMP paths. I wish you did not feel the need to include this assertion. Why not just get on and describe the benefits (as you do in the next sentence). Currently it really sounds like this is an idea that is strongly opposed and you are trying to justify it to the rest of the community. In fact, the community will judge according to the technical merits. --- Please don't use the word "draft" in the text as it creates work for the RFC Editor and might get missed in the publication process. Obviously, by the time this is published as an RFC it will no longer be a draft. Best thing to do is search and replace "draft" with "document". --- Section 1 Typically, forwarding hardware can deduce that an IP payload is being directly carried by an MPLS label stack, and is capable of looking at some fields in packets to construct hash buckets for conversations or flows. However, an intermediate node has no information on the type pseudowire being carried in the packet. Is the first sentence relevant to this document? I don't think so, but if you believe it is, I think you will need to add a statement about how this deduction is made. --- Section 1 In the case of a pseudowire emulating a high bandwidth trunk, the granularity obtained by hashing the default label stack is inadequate for satisfactory load-balancing. Is "the default label stack" intended to convey some special meaning? I suspect you are trying to say "the label stack that would be constructed if this I-D hasn't been implemented". You will simply have to go down the path of saying... In the case of a pseudowire emulating a high bandwidth trunk, the granularity obtained by hashing the label stack is inadequate for satisfactory load-balancing. --- Section 1 This draft proposes a method to introduce granularity on the hashing of traffic running over pseudowires by introducing an additional label, chosen by the ingress node, and placed at the bottom of the label stack. As above: s/draft/document/ Also, please be less timid. Your document defines a method. --- Section 1.1 s/1.1. ECMP in Label Switched Routers/1.1. ECMP in Label Switching Routers/ s/Label switched routers/Label Switching Routers (LSRs)/ --- Section 1.1 been proposed [I-D.kompella-mpls-entropy-label], however that is Reading would be significantly enhanced by forward reference to section 8. --- Section 3 It is recommended RECOMMENDED ? --- Section 3 It is recommended that the method chosen to generate the load balancing labels introduces a high degree of entropy in their values, to maximise the entropy presented to the ECMP path selection mechanism in the LSRs in the PSN, and hence distribute the flows as evenly as possible over the available PSN ECMP paths. It isn't clear to me that entropy is necessarily a good thing. It depends on the hash algorithm, doesn't it. --- Figure 2 Those four-octet things are not actually labels are they. --- What is the purpose of the T bit? Why would an implementation go to the trouble of including the flow-label TLV only to set T=0? --- Section 4 If PWE3 signalling [RFC4447] is not in use for a pseudowire, then whether the flow label is used MUST be identically provisioned in both PEs at the pseudowire endpoints. If there is no provisioning support for this option, the default behaviour is not to include the flow label. This paragraph is misplaced in the section on signaling. Please put it elsewhere. I am not convinced by the 2119 language in this paragraph since an implementation cannot control the behavior. --- Section 4 Do you not think that you should say that the new sub-TLV is carried in the Interface Parameters TLV, and on which messages? --- Section 4.1 o FL is the flow label sub-TLV identifier assigned by IANA. Can you either put in a [TBD] flag so the RFC Editor will catch this, or a forward pointer to section 10. --- Section 5 Consider an egress that doesn't support flow label, but previous S-PEs that do. In this case you are content to throw the baby out with the bath water? --- Section 6 We believe that this problem is addressed by the following two methods I would like you to be more definitive, please. But, that said, the subsequent bullets do not provide methods of addressing OAM in this case. Rather, the text attempts to say why the problem is not important. In my opinion it fails since, although ECMP is out of scope for MPLS-TP, a user has reasonable expectations that some of the flows on their PW will not be wiped out for the IGP convergence period, when (for example) rapid notification followed by change of the flow label could cause the traffic to be balanced differently and avoid the failure, or when a partial failure of a PW could trigger a switch to a different PW. --- Section 6 s/corruption of an/corruption of a/ --- You need to get rid of the reference to I-D.ietf-mpls-lsr-self-test This work has clearly been abandoned. --- s/Figure 4: Use of Router Alert LAbel/Figure 4: Use of Router Alert Label/ --- Figure 4 Shouldn't "payload" actually read "VCCV message"? Shouldn't you include the warning (from 5085) that inserting the router alert label probably breaks the ECMP hashing such that the packets will go another way. --- How funny that labels that are conventionally described as being "above" on the label stack are shown in your diagrams as below. --- Section 7 s/The methods describe/The methods described/ s/The method proposed/The method defined/ s/in those cased/in those cases/ s/The methods describe/The methods described/ --- Section 7 order is not maintained amongst packets of different flows. I know what you mean, but you have actually said something subtly different. --- Section 7 Ethernet may have this property, and for that reason this document focuses on Ethernet. Applications for other high- access-bandwidth PW's (e.g. Fibre Channel) may be defined in the future. Does the document really *focus* on Ethernet? There are a couple of places where Ethernet is cited as an example (but where the text says equally applicable, blah, blah) and two paragraphs a little below this statement that say "the Ethernet PW". Nothing else. Can't you generalise? --- Section 7 If sequence number support is required this mechanism is not applicable. It's stronger than that, isn't it? You need to prohibit the mechanism. But shouldn't you also prohibit ECMP? --- Section 7 Where it is known that the traffic carried by the Ethernet pseudowire is IP the method of identifying the flows are well known and can be applied. Such methods typically include hashing on the source and destination addresses, the protocol ID and higher-layer flow- dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. Either s/method/methods/ or s/are/is/ If these methods are so well known, you will have no difficulty in supplying a reference or two. I think you have mixed the method of identifying the flows with the method of hashing the flows into buckets. --- Section 7.1 In the ECMP case and the link bundling case the NSP may attempt to take bandwidth into consideration when allocating groups of flows to a common path. That is permitted, but it must be borne in mind that the semantics of a label stack entry (LSE) as defined by [RFC3032] cannot be modified, the value of the flow label cannot be modified at any point on the LSP, and the interpretation of bit patterns in, or values of, the flow label by an LSR are undefined. If you have something to say, you should say it. Otherwise your paragraph is lost on your readers. I think you are trying to say "There is no mechanism currently defined to indicate the bandwidths in use by specific flows using the fields of the MPLS shim header. Furthermore, since the semantics of the MPLS shim header are fully defined in [RFC3032] and [RFC5462], those fields cannot be assigned semantics to carry this information. This document does not define any semantic for use in the TTL or TC fields of the label entry that carries the flow label, but requires that the flow label itself be selected with a high degree of entropy suggesting that the label value should not be overloaded with additional meaning in any subsequent specification." --- Section 7.1 A different type of load balancing is the desire to carry a pseudowire over a set of PSN links in which the bandwidth of members of the link set is less than the bandwidth of the pseudowire. This problem is addressed in [I-D.stein-pwe3-pwbonding]. Such a mechanism can be considered complementary to this mechanism. The referenced I-D seems to be dead. I'm not quite sure why you need to reference it here. How about just taking out the paragraph? --- Section 7.2 appears to describe exactly the link bundling case that you discussed in section 7. I have recently noticed considerable confusion between link bundles and LAG and suggest you restrict LAG to be a data link function that is below the level of an "interface" in the IP/MPLS world. That does not mean that an individual node, knowing (by unspecified means) that it is about to use an interface that is constructed from a LAG, can't hash the traffic across the LAG. Ultimately, you should consider ECMP (i.e. multiple IGP paths) where each hop on each path may be made a link bundle, and where each component link of a bundle may be supported by LAG. Can you go back and check that you have used the language precisely. --- Section 7.4 If the payload on a PW is made of a single inner flow (i.e. an encrypted connection between two routers), or the flow identifiers are too deeply buried in the packet, then the functionality described in this document does not give any benefits, though neither does it cause harm relative to the existing situation. Is that s/i.e./e.g./? "Too deeply buried" meaning "If the NSP cannot access sufficient information to distinguish flows, perhaps because the protocol stack is too deep for its capabilities..."? Is the statement about "no harm" necessary? After all, the mechanism will simply not be used in this case. --- Section 7.4 The most common case where a single flow dominated the traffic on a PW is when it is used to transport enterprise traffic. Enterprise traffic may well consist of a large single TCP flows, or encrypted flows that cannot be handled by the methods described in this document. s/dominated/dominates/ s/a large single TCP flows/large TCP flows/ Note that this second half of the paragraph is a non-sequitur from the first half. You probably need to wrap the whole paragraph with a thought about single or dominant large flows. --- Section 7.4 1. The operator can do nothing and the system will work as it does without the flow label. s/can do nothing/can choose to do nothing/ --- Section 7.4 An operator has six options under these circumstances: :-) You tease! There are only five listed. --- Section 7.4 s/an single flow/a single flow/ --- Section 7.4 5. The operator could configure the ingress to assign a label of special significance (such as a reserved label) to all high bandwidth flows so that some other action (not specified in this document) could be taken on the flow. I think you need to delete this as it contradicts two specific statements made elsewhere... 1. MUST NOT use a reserved label as the flow label 2. MUST NOT assign semantics to the flow label --- 8. Applicability to MPLS While I see where you are coming from, I must point out that the whole of your document is about MPLS. Could you come up with a better title? --- Section 9 The ingress PE SHOULD take steps to ensure that the load-balance label is not used as a covert channel. Again, you are saying something between the lines :-( Since the ingress PE allocates the label (isn't it called the flow label not the load-balance label?) the "SHOULD take steps" is very odd! And why is this a security requirement? How would security be compromised? --- Section 9 This document has signaling extensions in it, so you should reference RFC 4447 from this section. You should also reference RFC 5920. --- Section 9 The flow label TTL should therefore never be considered by the forwarder, and hence SHOULD be set to a value of 1. This will prevent the packet being inadvertently forwarded based on the value of the flow label. Note that this may be a departure from considerations that apply to the general MPLS case. But you have previously said that the flow label TTL is never used to discard a packet based on TTL expiry [section 1.2]. You need to make your mind up. And, if there are rules you wish to apply for setting fields, you need to put them in the main part of the protocol spec, not buried in the security section. And (while I'm at it) how is this a security feature? Oh, and another thing... The sequence of your logic is broken. It would be fine to say: If the flow label is inadvertently examined as if it were a normal label, the packet might be forwarded. This can be prevented by setting the associated TTL to 1. But I don't think that "should never be considered" leads to "should be set to 1". Finally, the note at the end is at best unhelpful. What are you trying to say, and why? --- Section 10 Please change this text to reference early allocation that has been made for you. Note that the value 17 has NOT been assigned (although the value 0x17 has). |
|
2011-01-22
|
07 | Adrian Farrel | State changed to AD Evaluation from Publication Requested. |
|
2011-01-19
|
07 | Cindy Morgan | (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 … (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? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (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, the document has received adequate review. The document has been developed of a lengthy period of time with regular discussion within the working group. (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 specific concerns. (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? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. (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.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (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]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists and seems reasonable. (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? There are no sections that use a formal language. (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 Where identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on label stacks and use this to balance flows over ECMPs. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. Document Quality There are no concerns with document quality. Personnel Who is the Document Shepherd for this document? Matthew Bocci (matthew.bocci@alcatel-lucent.com<mailto:matthew.bocci@alcatel-lucent.com>) Who is the Responsible Area Director? Adrian Farrel |
|
2011-01-19
|
07 | Cindy Morgan | Draft added in state Publication Requested |
|
2011-01-19
|
07 | Cindy Morgan | [Note]: 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd' added |
|
2010-10-22
|
05 | (System) | New version available: draft-ietf-pwe3-fat-pw-05.txt |
|
2010-07-09
|
04 | (System) | New version available: draft-ietf-pwe3-fat-pw-04.txt |
|
2010-01-27
|
03 | (System) | New version available: draft-ietf-pwe3-fat-pw-03.txt |
|
2009-10-24
|
02 | (System) | New version available: draft-ietf-pwe3-fat-pw-02.txt |
|
2009-09-23
|
01 | (System) | New version available: draft-ietf-pwe3-fat-pw-01.txt |
|
2009-07-02
|
00 | (System) | New version available: draft-ietf-pwe3-fat-pw-00.txt |