Yaakov Stein <yaakov_s <at> rad.com>
2007-12-03 22:13:40 GMT
not sure what you mean by "IP PW".
mean simply IP over MPLS ?
that case, yes the CW first nibble is designed to help with load
understand this draft, the question is load balancing of PW
being an operator, I am not sure how important this is.
OK, so speaking as yet another operator....
there's a clear
need to support fat PWEs, but I'm yet to be convinced that this draft is the
correct solution to the problem.
The intro to the draft talks about the
application being to interconnect IP routers. If that's the case then why not
use an IP pseudowire? If you do that then there will just be one label,
but (AFAIK) many routers will spot the 0x4 (or 0x6) in the first nibble of the
payload and do a hash on the IP header - giving optimum traffic distribution and
also preserving the order of each flow.
If the payload is not IP then I
think we have a problem at any rate, as we don't necessarily know how to
identify a "flow". Sure, you could do a MAC hash for an Ethernet
pseudowire, but in many cases you see precisely one pair of MAC addresses on the
On Nov 28, 2007 2:47 PM, Shane Amante <shane <at> castlepoint.net
Speaking as /another/ operator, I can say there is an
Yaakov Stein wrote:
> Stewart and other
> I just finished reading the FAT-PW draft, and have a
> 1. The draft says "Operators have
requested the ability..."
> Since I have never heard this
request from any of the operators with
> which we work,
can this be changed to "Some operators have requested ..." ?
Since there is one operator on the author list, I guess we can
> which operator has requested
> this feature
need to solve this problem, (and, has been for quite a
actually). Consider the fact that 10 GbE has become (is
pretty common access circuit to Backbones and that within most
networks the dominant Backbone link size are 10G. As you're likely
aware, the IEEE HSSG is working on both 40 GbE and 100 GbE. Once
is available, (and assuming its used for WAN connectivity,
similar to 10 GbE LAN PHY), then OC-768c Backbone links will suffer
same problem. 100 GbE will, eventually, be used as both core and
links. In short, this problem is not going away. We need
to solve it.
From my perspective,
Ethernet is far and away the biggest "problem
> 2. The example given is for Ethernet PWs.
Is this draft limited to this
> There is
discussion of whether it is limited to IP over Ethernet,
but this more basic question is not addressed.
example, could this load balancing to be performed for ATM PWs
based on the AAL5 flows?
child" out there today, due
to the size of access to Backbone links,
(see above). While it may be
admirable to look at making this draft
"generic" for a variety of PW
types, I wouldn't lose any sleep if this
draft remained focused on just
When I read the draft, this is the
part I also had the most concern
> 3. PWs are an emulation of the native
> Why is this emulation being called upon to
deliver a feature NOT
> present in the native service ?
Doesn't this break the model a bit?
> 4. A native service
processing function is required for differentiating
> between different
> at ingress. If this draft is indeed limited to
Ethernet PWs, such a
> processing function
exists in the native service. 802.3 clause 43 (LAG) defines
> for exactly this purpose (commonly
implemented by hashing IP
> addresses and port numbers),
and even mentions the use of load balancing in the distribution
> conversations over links.
> I think this
function should be at least referenced.
> 5. My greatest problem
is with the prefered mode of section 1.1,
> which builds a
PW label stack under the MPLS label stack.
> The proposal
is for 2 PW labels (once again, somewhat breaking RFC3985).
Figure 2 is not completely clear about the label structure.
There are two possibilities:
> 1) both
load balancing label and PW label have stack bit set. (I
> hope not
> 2) the load balancing label has S=1, and the PW
label has S=0.
> So formally, the PW
label seems to be an MPLS label.
> Both possibilities
break the standard model.
> I would certainly like
to see more justification of the problem
> before breaking
the model in this way.
> Perhaps a short requirements
document is in order?
with. In particular, I like the
"simplicity" of the LB Label approach
(i.e.: savings on FIB space, no need
to signal first and last labels for
each PW, etc.); however, I am concerned
about the implications of, or
potential need to, define a 'generic' MPLS PW
My primary concern is future extensibility. Specifically,
in case there
are /other/ applications, which may or may not have been
brought to the
surface, yet, that may have similar needs/desire for a 2nd
PW label. If
that ultimately means we gain consensus to amend the
I'm OK with that, but certainly we would need to have
more discussion to
see whether or not it is a good approach and, more
importantly, what are
the other implications that go along with it?
Load-balancing over LAG and ECMP paths, using some number of
> 6. The draft recommends generating a load
balancing label in such fashion
> that the entropy is
high. This assumes that the precise form of the
is used to determine the load balancing path (possibly a hash
> some sort).
> Could this mechanism, even if
beyond the scope of the document, be
> explained a bit more ?
as input to a load-balancing hash algorithm, is common across
vendors. However, such algorithms are 'proprietary' to each
I'm not sure how much more can be said other than the fact that,
would strongly prefer that the output of a LAG or ECMP hashing
is spread out among the largest number of hash buckets, (as
practical), to get the most even distribution of flows across a set of
links in a LAG or ECMP path. And, I think the draft already makes
point, in 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
flows as evenly as possible over the available PSN
Is there something else you had in mind?
> 7. With the optional mode of section 1.2
several PW labels are mapped to
> a single AC.
have no problem with this approach. In fact, I feel that it is
somewhat similar to the solutions being proposed for PW
> For PW protection two labels mapped to the
AC or end-user application,
> where one label belongs to
the active PW, and the other to the
> backup PW (not being
> For load balancing two or more PWs, all in active
state, are mapped
> to the same AC.
> Would it be
possible to integrate the two features into one mechanism
for mapping multiple PW labels in either active or backup state
> one AC or end-user identifier?
> 8. The term VC as
opposed to PW is used in various places in the document.
I am not sure what is meant here. Is the intent that a "VC" is one
the paths of the
> load-balanced "PW" ?
The first paragraph of section 4 seems to imply that the authors are
willing to settle
> on either of the modes rather than both. I would
support the PW label mode.
> If some entropy-rich information needs to
be placed in the packet,
> perhaps the flags in the CW could be used (if
16 paths is sufficient).
pwe3 mailing list
pwe3 <at> ietf.org