Re: [mpls] Comments on draft-cheng-mpls-inband-pm-encapsulation

[Weiqiang Cheng <[e-mail]>]

Hi Tarek,

Many thanks for your insightful comments/queries.

We've discussed them, please see inline our responses with <Weiqiang>.

Please let us know whether our responses are acceptable to you.

 

Best Regards,

Weiqiang (on behalf of co-authors)

发件人: mpls [mailto:[e-mail]] 代表 Tarek Saad
发送时间: 2020年7月22日 02:43
收件人: [e-mail]
抄送: [e-mail]
主题: [mpls] Comments on draft-cheng-mpls-inband-pm-encapsulation

 

Hi authors,

I have the following comments/queries on this draft:

1.  Using SFL approach, an egress could assign a unique transport label per flow. Hence, it would be possible to use the SFL label on a transit as well as on egress for flow identification purpose

<Weiqiang> If SFL approach is extended to support flow identification on a transit as you described, then we need a mechanism to gurantee the uniqueness of transport label within the administrative domain, and we need to put state on the transit to tell it whether or not the transport label is an SFL, and we need to have a signaling protocol to populate the state on every transit. All these requirements make SFL approach complex and undeployable.

2.  Or, is the intention to identity flows when transported over the same LSP using same transport label?

<Weiqiang> Yes, correct. One or more flows can be transported over the same LSP using the same transport label.

3.  I see a lot of similarity between Entropy Label and Flow Label. Both are assigned per flow (whatever the definition of a flow is). Currently, EL is assigned by ingress, but in theory it can be assigned by NMS (e.g. global too). What are your thoughts on using EL to identify a flow?

<Weiqiang> Very good observation, in many aspects they are the same. But, they have the key difference that EL's "only purpose in the label stack is to provide "entropy" to improve load balancing" [RFC 6790], nevertheless FL is used to identify a flow (the definition of a flow is up to the network operator), in other words they're orthogonal and can be present in the same label satck. If we use EL to identify a flow, then we actually redefine EL and we'll lose the EL's functionality defined in RFC 6790.

4.  The draft does not discuss implications of device readable label depth on placement of FLI/FL (e.g. when SR Paths are used as transport)

<Weiqiang> Thanks for pointing this out, we'll add a new section in the next rev on this. We believe the implications of FLI/FL are similar to that of ELI/EL when SR Paths are used as transport, which has been discussed in RFC 8662 in depth, we'll reference to that document when applicable. By the way, due to the fact that FLI/FL may appear more than once in a label stack, we kindly ask the MPLS WG to consider the possibility to assign a bSPL for FLI.

5.  The draft hints to leveraging TC bits in MPLS header to identify alternate markings for same flow.. This is indeed unusual and would be hard to standardize. Why can’t 2 flow-ID labels be allocated to the same flow for the purpose of alternate marking?

<Weiqiang> Due to the fact that double marking method (as defined in RFC 8321, two marking bits needed, one for loss and another for delay) can get to more accurate measurement results, if we don't use TC bits, then we need 4 flow-ID labels for each flow as alternate marking, that means a lot of wasted flow-ID resource, more importantly, we need a mechanism to tell the transit which 4 flow-ID labels are allocated to the same flow, and populate the state on every transit, that's too complex and hard to deploy. With respect to TC bits standardization, we noticed in section 2.1 of RFC 5462 it says "RFC 3270 <https://tools.ietf.org/html/rfc3270>  and RFC 5129 <https://tools.ietf.org/html/rfc5129>  update the definition of the TC field and describe how to use the field", so we suggest an update on this part of text as below.

OLD:

   Besides flow identification, a color-marking field is also necessary
   for alternate marking method.  To achieve the purpose of coloring the
   MPLS traffic, it's RECOMMENDED to reuse the Flow-ID Label's TC, i.e.,
   using TC's highest order two bits (called double-marking methodology
   [RFC8321 <https://tools.ietf.org/html/rfc8321> ]) as color-marking bits.  Alternatively, one more specific
   MPLS color-marking label may be placed immediately following the
   Flow-ID label.
   
NEW:
   Besides flow identification, a color-marking field is also necessary
   for alternate marking method.  To achieve the purpose of coloring the
   MPLS traffic, the current practice when writing this document is to reuse the Flow-ID Label's TC, i.e.,
   using TC's highest order two bits (called double-marking methodology
   [RFC8321]) as color-marking bits.  Alternatively, allocating multiple 
   Flow-ID Labels to the same flow may be used for the purpose of alternate marking.

 

 

Regards,

Tarek

 

Juniper Business Use Only