Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

["Chengli (Cheng Li)" <[e-mail]>]

Hi Ketan,

Thanks for your comments! Sure, will add text to describe it. BTW, if we need to write a new draft, you are really welcome to do it together!

Best,
Cheng


From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Thursday, April 9, 2020 7:33 PM
To: Chengli (Cheng Li) <[e-mail]>; Susan Hares <[e-mail]>; 'IDR List' <[e-mail]>
Cc: SPRING WG <[e-mail]>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Hi Cheng,

Thanks for your responses and clarifications. They help get a better understanding for what exactly the authors wish to specify for "Path MTU" for SR Policy. Will look forward to normative text with description of computation and behaviours expected from both the entity computing this Path MTU value and it's handling on the headend. I would request description text in the draft instead of a normative reference to RFC3209.

That said, I still don't believe this belongs to an IDR document. The draft-li-idr-sr-policy-path-mtu should limit itself to the BGP encodings. I would suggest to move the specification of SR Policy Path MTU into a new draft positioned in the Spring WG. That IMHO would be the right way to progress this work.

Thanks,
Ketan

From: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Sent: 09 April 2020 16:27
To: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; 'IDR List' <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Hi Ketan,

Thanks for your reply, please see my reply inline.

Cheng



From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; 'IDR List' <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Hi Cheng,

Please check inline below.

From: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; 'IDR List' <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Hi Ketan,

Many thanks for your comments, and sorry for my delay, please see my reply inline.

Thanks,
Cheng


From: Idr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, April 3, 2020 4:18 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; 'IDR List' <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Hello,

I have a few questions for the authors of this draft and some discussion points for the WG.

1)      What is precisely the definition of this "path MTU" for an SR Policy? I am guessing that it includes all the labels/SIDs that are used for the SR path?
[Cheng] Yes, The Path MTU describes the largest size of the packet, including the overhead of Labels/SIDs/IPv6 header/SRH and others.
[KT] Here, "path" is the SR path and the SR path is specified by a label stack. So the "payload" over the SR path does not include the SID List use to construct the path itself, right? Or do you mean that the "path MTU" is the lowest MTU value of all paths over which packet steered over the SR Policy may go over?

[Cheng] The path here is the SR path specified by a SID list.  The PMTU is the lowest MTU value of the MTU of the Links along the path identified by the SID list. It is the largest size of the packet to be sent along the SR path (SID List), so it can include the payload, overhead of SR, FRR and may be Binding SID (an Binding SID will introduce a new IPv6 encapsulation or a new SRH).

When encapsulating a packet, the length of the payload(inner IP packet or something else) should be less than the PMTU minus the overhead of SID List/SRH/ FRR overhead and Binding SID overhead, but it is a implementation choice.
[KT] Here a "path MTU" object is being defined. It is to be calculated by a component X and communicated over BGP protocol to a node/component Y. IMHO we cannot leave such things to implementation aspects - this attribute should be clearly specified so that both X and Y have the same understanding of what it means and how it is to be used.

[Cheng] Well, as I mention above, this value is the largest value of the MTU of links along the path. This value can be calculated very precisely. However, when we encapsulate the packet, how long  the payload can be, it depends on the implementation.
                 For example, device A can encapsulate M byte, and M =  PMTU -  A(overhead of SR) - B (FRR overhead), and the FRR overhead may be 40 Bytes. But for device B, the FRR overhead may be 56 bytes, it depends on the policy.

                 But you may be right, we can calculate the TRUE PMTU on X (Controller, etc.) , and send it to the device, and the device will use it as the longest length of the Payload, that will be fine. We can discuss about this.



2)      While https://tools.ietf.org/html/rfc3209#section-2.6 defines "path MTU" for RSVP-TE LSPs, it does describe the procedures for the same for handling IP packets/payloads on the headend. It does not cover the scenarios where the incoming packets may be themselves labelled.
[Cheng]Well, I may misunderstand the text in https://tools.ietf.org/html/rfc3209#section-2.6, but I think it covers the scenarios where the incoming packets may be themselves labelled. I may be wrong.

   "
   The following algorithm applies to all unlabeled IP datagrams and to
   any labeled packets which the node knows to be IP datagrams, to which
   labels need to be added before forwarding.  For labeled packets the
   bottom of stack is found, the IP header examined.


   Using the terminology defined in [5<https://tools.ietf.org/html/rfc3209#ref-5>], an LSR MUST execute the

   following algorithm:



   1. Let N be the number of bytes in the label stack (i.e, 4 times the

      number of label stack entries) including labels to be added by

      this node.
       "
[KT] May be I misunderstood your proposal then. It seems that the authors want the headend to perform the behavior described in RFC3209 Sec 2.6 for SR Policies, then please specify the same with normative language. How would this work for SRv6? This way the WG can review and understand what the proposal is. Note that we can also have a label stack introduced during transit due to something like TI-LFA.

[Cheng] Yes, that is what I mentioned above, some overhead will be introduced like FRR/TI-LFA.  Will add the text to specify how to do it in SRv6.


3)      Shouldn't the concept of "path MTU" for SR Policies and its' applicability and operations be first defined in a (Spring WG?) document before we introduce its signalling aspects in protocols like BGP? Note that such a document would bring in requirements and guidelines for how the value is going to be computed and it's usage for different steering mechanisms over SR Policies.
[Cheng] This is a really small but useful and straight forward extensions, it might not need to write a draft to describe the requirement instead of adding text in the current SR policy architecture draft or it current document.
[KT] It is not about the size of the document, but the clear and normative specification of behaviors being introduced - both for the node calculating this value and for the headend for how it is supposed to handle this. My worry is that there is devil in the details here and operational aspects on how exactly this will work. I am not against this work. I only ask the authors to document the behaviors associated with this in a Spring WG document so the WG can review all that is entailed by the proposal. It is somewhat similar to how Path Segment was introduced - I would suggest to start with a fresh draft using much of the content from this BGP document plus other clarifications as discussed in this email thread.

Once the "Path MTU" for SR Policy is properly specified, the BGP SRTE encoding is actually trivial by simply referring to its base draft. The same may be also specified via PCEP or a Yang model.

                 [Cheng] Agree with your proposal. We should specify the behavior clearer. The question is that do we need to write a new draft in SPRING to describe it ? or describe it in the BGP draft directly? Or add text in the existing SR policy architecture draft? We can discuss this. But for sure, will add text to specify this part.


4)      Finally, specific to the proposed encoding here, would this "path MTU" not be more suitable on the CP level since each SL may have different size label stack and different paths and one does not know which SL would be picked for a particular flow? So may be the lowest value computed for all SLs is what gets applied to the packets at the CP (i.e. SR Policy) level?
[Cheng] You are correct. The PMTU is defined for SID List. When we talk about Path MTU for SR policy, it CAN be the lowest value of the PMTU of SID lists. But do we need this value? If we need, then the node can compute it based on PMTUs.
[KT] Sure. I think these are details and we can leave them aside for now. My main concerns are the previous comments.

Thanks,
Ketan

Thanks,
Ketan


From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: 30 March 2020 18:06
To: 'IDR List' <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

This begins a 2 week WG adoption call for draft-li-idr-sr-policy-path-mtu-03.txt

You can view this draft at:
https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/

This draft distributes path maximum transmission unit for the
SR policy via BGP.

Any discussion regarding on whether one desires
SR Policy should be clearly distinguished from the
Technical discussions on the mechanisms to pass SR policy MTU.

The questions for the people to discuss on this draft are:

1) Is there a need for this mechanism in networks using
        MPLS-SR or SR-V6 and SR policy?

2) Are there any error handling issues besides what is being
     Taken care of in RFC7752bis-03.txt

3) Do you think this draft is ready to be adopted?
     In this category, please list any concerns you have
     regarding adoption.  This category can include
     general concerns about BGP-LS, MPLS-SR,
    SR-V6, and SR-Policy.

Cheers, Sue Hares