Subject: [PWE3] draft-bryant-filsfils-fat-pw

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 28 Nov 2007 10:00:09 +0200

Stewart and other authors
 
I just finished reading the FAT-PW draft, and have a few
comments/questions.
 
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 guess
which operator has requested
    this feature !
 
2. The example given is for Ethernet PWs. Is this draft limited to this
case?
    There is discussion of whether it is limited to IP over Ethernet, 
    but this more basic question is not addressed.
    For example, could this load balancing to be performed for ATM PWs 
    based on the AAL5 flows?
 
3. PWs are an emulation of the native service.
   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 flows
   at ingress. If this draft is indeed limited to Ethernet PWs, such a
processing function
   already exists in the native service. 802.3 clause 43 (LAG) defines
conversations
   for exactly this purpose (commonly implemented by hashing IP
addresses and port numbers),
   and even mentions the use of load balancing in the distribution of
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?
 
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
label
    is used to determine the load balancing path (possibly a hash of
some sort).
    Could this mechanism, even if beyond the scope of the document, be
explained a bit more ?
 
7. With the optional mode of section 1.2 several PW labels are mapped to
a single AC.
    I have no problem with this approach. In fact, I feel that it is
    somewhat similar to the solutions being proposed for PW protection.
    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 used).
    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 to
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
of 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).
 
Y(J)S
 
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 28 Nov 2007 10:52:28 +0000

Yaakov Stein wrote:
>     Since I have never heard this request from any of the operators 
> with which we work,
>     Since there is one operator on the author list, I guess we can 
> guess which operator has requested
>     this feature !
OK.
>  
> 2. The example given is for Ethernet PWs. Is this draft limited to 
> this case?
The most pressing demand is Ethernet, since Ethernet has a higher
potential access b/w to core b/w ratio than any of the other PWs
we have designed.

However whilst I see less need to deploy the technology with
other PW types, I see no reason to limit the draft to Ethernet.
For example, I suppose we might need to use this for some
data center connectivity such as Fibre Channel.
>    Doesn't this break the model a bit?
The issue is to try to increase the effective core to edge bandwidth ratio.

In architecture terms you could consider that the NSP broke the native 
service into
a number of flow groups and then multiplexed flows onto a number of
parallel PWs. The issue is then whether we then map these flow groups
onto a number of pseudowires (multi PW label approach) or a single
PW with some form of multiplexing indicator.

So I think that the multiple PW label approach is entirely consistent with
RFC3985. However I think that the load balance label approach results
in better load balancing, and uses fewer MPLS FIB entries.
>  
> 4. A native service processing function is required for 
> differentiating between different flows
We were not aware of that. Please can you provide us with a reference
and we will take a look at it (and of course add it to the draft).
>      1) both load balancing label and PW label have stack bit set. (I 
No - this would defeat the load balancers!
>     Both possibilities break the standard model.
This is the case we propose, and I agree that it is not
covered by RFC3985 and that an extension is needed.
However the PW label (outer label) still is the one that the
egress PE processes just as it does today and it is this label
that provides the context. However the operation
identified by the context needs to be changed from strip
PW label and CW and sent to interface X (maybe with
some VLAN operation), to strip (PW label and
LB label (without looking at it) ) and continue as before.

>    Perhaps a short requirements document is in order?
OK we will provide some more context in the draft. There is
more context in the slide deck that will be presented.
> 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 label
Discussion of the MPLS label stack hash mechanism has
always been a sensitive subject in the IETF. Clearly our
assumption is that the label with the S-bit = 1  is a component
of the hash for non-IP packets, and I think this is common
across the P router vendors. Certainly of all the labels in
the stack, the one with the S bit =1 is the only one that
a PW is able to influence.

However the draft does need some more text on this subject and this
can be added.
>  
> 7. With the optional mode of section 1.2 several PW labels are mapped 
> to a single AC.
>     For load balancing two or more PWs, all in active state, are 
> mapped to the same AC.
With hindsight I think that we need to make this the default mechanism,
(for backward compatibility reasons) although I am concerned that it will
not work as well as mechanism described in section 1.1 which has
much better statistical properties.
>     Would it be possible to integrate the two features into one mechanism
I need to think about this.
>  
> 8. The term VC as opposed to PW is used in various places in the document.
It is the term used in RFC4447. We well take a look at where we used
it and add some clarification.
> on either of the modes rather than both. I would support the PW label 
It's difficult. One mode is MUCH better than two, but the mode that is
more powerful needs an extension to RFC3985 and requires a change to
the PE design.

PWE3 WG needs to discuss the issues and form a conclusion. Lets
digest the issue and form considered opinion on the best way to go
forward.
> perhaps the flags in the CW could be used (if 16 paths is sufficient).
That does not work - please see RFC4928.
- Stewart

---

From: Shane Amante <[email-masked]>
Date: Wed, 28 Nov 2007 07:47:31 -0700

Hi Yaakov,

Yaakov Stein wrote:
> I just finished reading the FAT-PW draft, and have a few comments/questions.
>  

Speaking as /another/ operator, I can say there is an absolutely strong 
need to solve this problem, (and, has been for quite a long time, 
actually).  Consider the fact that 10 GbE has become (is becoming?) a 
pretty common access circuit to Backbones and that within most SP 
networks the dominant Backbone link size are 10G.  As you're likely well 
aware, the IEEE HSSG is working on both 40 GbE and 100 GbE.  Once 40 GbE 
is available, (and assuming its used for WAN connectivity, perhaps 
similar to 10 GbE LAN PHY), then OC-768c Backbone links will suffer the 
same problem.  100 GbE will, eventually, be used as both core and access 
links.  In short, this problem is not going away.  We need to solve it.

>     For example, could this load balancing to be performed for ATM PWs

 From my perspective, Ethernet is far and away the biggest "problem 
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 Ethernet.

>     The proposal is for 2 PW labels (once again, somewhat breaking RFC3985).

When I read the draft, this is the part I also had the most concern 
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 label.

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 PWE3 Architecture, 
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?

>     Could this mechanism, even if beyond the scope of the document, be 

Load-balancing over LAG and ECMP paths, using some number of MPLS labels 
as input to a load-balancing hash algorithm, is common across all 
vendors.  However, such algorithms are 'proprietary' to each vendor. 
I'm not sure how much more can be said other than the fact that, one 
would strongly prefer that the output of a LAG or ECMP hashing algorithm 
is spread out among the largest number of hash buckets, (as is 
practical), to get the most even distribution of flows across a set of N 
links in a LAG or ECMP path.  And, I think the draft already makes this 
point, in Section 3:
---snip---
    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.
---snip---

Is there something else you had in mind?

-shane

>     For PW protection two labels mapped to the AC or end-user application,
> on either of the modes rather than both. I would support the PW label mode.
> ------------------------------------------------------------------------
>