[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Yaakov Stein wrote:
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 !
OK.
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? 
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.
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? 
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
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. 
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).
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 !)
No - this would defeat the load balancers! 
     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.

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.

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?

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
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 ? 
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.
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. 
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
for mapping multiple PW labels in either active or backup state to one AC or end-user identifier?
I need to think about this.
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" ? 
It is the term used in RFC4447. We well take a look at where we used
it and add some clarification.
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. 
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.

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).

That does not work - please see RFC4928.
- Stewart


_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3