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

["Yaakov Stein" <yaakov_s at rad.com>]

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
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3