Subject: [PWE3] MS-PW Signaling procedure of flow label in draft-ietf-pwe3-fat-pw-05

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 2 Dec 2010 15:53:13 -0600

Stewart and co-authors,
I would like to raise an issue with Section 5 of draft-ietf-pwe3-fat-pw-05 and discuss a proposal to address it. 

This section currently reads as follows:
"
5. Multi-Segment Pseudowires

   The flow label mechanism described in this document works on multi-
   segment PWs without requiring modification to the Switching PEs
   (S-PEs).  This is because the flow label is transparent to the label
   swap operation, and because interface parameter Sub-TLV signalling is
   transitive.
"

This means that the use or not of the flow label is entirely under the control of T-PE nodes. S-PE nodes have no say in its use. There are use cases where an operator wants to disable the use of the flow label on MS-PW when one or more segments of that MS-PW traverse specific domains or areas of the network. 

For instance, The inclusion of FAT label has the impact of bandwidth overhead and the spreading of packets of the same PW over multiple ECMP paths. When this is not desired in a specific domain, it is easier to have the S-PE at the entrance of this domain filter out the sub-TLV than to have the operator go to the T-PE nodes an disable it only on MS-PWs which traverse this domain. It is even more challenging in the case of dynamic MS-PW as the path of the MS-PW may be based on BGP routing and thus it will be hard for the operator of the T-PE to figure out if the path will traverse those specific domains.

We would therefore like to add the ability of an S-PE to filter out the Flow Label sub-TLV in a similar way the VCCV capability options can be filtered out in draft-ietf-pwe3-segmented-pw-18.txt. In other words, if an S-PE is configured to not allow the use of flow label on a given MS-PW, then the S-PE will filter out the Flow Label sub-TLV before passing the Label Mapping message downstream and the net effect is that flow label will be disabled end-to-end on that MS-PW. 

Of course for segmented PWs as in draft-ietf-pwe3-segmented-pw-18.txt this option can be configured on a per MS-PW basis at the S-PE. For dynamic MS-PW as in draft-ietf-pwe3-dynamic-ms-pw-13.txt, the S-PE can use a knob per system or per interface to enable this behaviour. This is of course up to implementations to decide.

I appreciate if you could let me know if you can accommodate this change. I understand this draft passded the WG last call but this behaviour is straighforward and already used in draft-ietf-pwe3-segmented-pw-18.txt for VCCV capability signaling over a MS-PW. I will provide the text if we have an agreement.

Thank you.
Mustapha.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 20 Dec 2010 10:01:46 +0000

There has been no discussion on this, thus I do not know whether to make 
a change and if I am to make a change, what text to add.

The concern that I have with this proposal is that if an SPE silently 
removed the TLV, the TPEs will have no idea why their mutually request 
for a FAT path was declined, thus the change needs to be more complex 
than simply allowing an SPE to remove the TLV.

I do not really subscribe to the b/w argument since we are talking IP 
packets in the client layer here so the extra 4 bytes seems an 
irrelevance. Nor do I subscribe to the allergy to ECMP in this element 
of the server network since if it did not like ECMP it would not have 
enabled it.

My personal inclination is the reject the request for change, but I 
really need to hear the views of other members of the WG.

- Stewart (speaking as FAT PW editor)

On 02/12/2010 21:53, Aissaoui, Mustapha (Mustapha) wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>