Skip to main content

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