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

From: "Weiqiang Cheng" <[email-masked]>
Date: Thu, 2 Apr 2020 14:27:31 +0800

The use case is valid.

Support the adoption. 

B.R.

Weiqiang Cheng

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <[email-masked]>
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

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 3 Apr 2020 07:38:26 +0000

Hi WG,

I support this document to be adopted since the mechanism is useful and the text is mature.

[Cheng ] Yes. The PMTU should be calculated and set for SID list in order to appropriately encapsulate SRv6 Packet.
Also,  overhead of BSID and FRR should be considered when calculating PMTU, so it will be good to provide a protocol interface for Controller to set the PMTU for SID list based on different PMTU considerations.

[Cheng] I think no. But the error handling should align with the error handling in https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-08#section-5
Will update it in next revision.

[

When the error determined allows for the router to skip the malformed
   NLRI(s) and continue processing of the rest of the update message,
   then it MUST handle such malformed NLRIs as 'Treat-as-withdraw'.
]

[Cheng]I think it is ready to be adopted.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 8:36 PM
To: 'IDR List' <[email-masked]>
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

Cheers, Sue Hares

---

From: Huzhibo <[email-masked]>
Date: Fri, 3 Apr 2020 07:53:08 +0000

Traditional MPLS uses the LDP / RSVP protocol to obtain the Path MTU. Segment Routing removes the LDP / RSVP protocol and requires a new mechanism to calculate the Path MTU.
Support Adaption.

Thanks

Zhibo Hu

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年3月30日 20:36
收件人: 'IDR List' <[email-masked]>
主题: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

Cheers, Sue Hares

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 3 Apr 2020 08:14:49 +0000

I support the adoption.
MTU is essential for a tunnel of any kind, either a default/blind one, or a better/optimized one provided optionally.
This document defines a direct and simple extension to provide an MTU for a tunnel rather than the default one.

Thanks
Jingrong

Cheers, Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 3 Apr 2020 08:17:52 +0000

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

Thanks,
Ketan

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

Cheers, Sue Hares

---

From: <[email-masked]>
Date: Fri, 3 Apr 2020 17:18:36 +0800

I  support the adoption. Thanks.

B.R.

Zhu Yongqing

发件人: Idr <[email-masked]> 代表 Susan Hares
发送时间: 2020年3月30日 20:36
收件人: 'IDR List' <[email-masked]>
主题: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG
adoption call (3/30 - 4/13)

SR policy via BGP.  

    SR-V6, and SR-Policy.   

Cheers, Sue Hares

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 3 Apr 2020 17:27:53 +0000

I have read the draft-li-idr-sr-policy-path-mtu-03 and I think it is very important subject to be specified. Therefore I support the WG Adoption of the draft, with the following comment:

The draft should add a paragraph to describe why can't each node simply drop the packet if the packet size is larger than it can support?
Since virtually all hosts send out MTU discovery (RFC8201) packets, if the network drops the packet due to the size exceeding the MTU, the source hosts will adjust the packet size. For communication between hosts, there are many layers of encapsulation added. Not just SR domain. The hosts have to adjust its packet size to reach their communication peers.

My two cents,

Linda Dunbar

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

You can view this draft at:
https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-idr-sr-policy-path-mtu%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C145ecee6a20e494beeb008d7d7a7399e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637214985553217711&sdata=cWgKd3GWCwcFaIyV%2FLn1KBWeaopBQdaOkXNQyFi5JvM%3D&reserved=0>

Cheers, Sue Hares

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 5 Apr 2020 17:54:26 +0800

Hi WG,
    Suport the adoption.

BR.
BING YANG

[email-masked]
 
From: Susan Hares
Date: 2020-03-30 20:35
To: 'IDR List'

 

 

Cheers, Sue Hares

---

From: stefano previdi <[email-masked]>
Date: Tue, 7 Apr 2020 13:13:29 +0200

I support the adoption. 

Thanks.
s.

> On Mar 30, 2020, at 2:35 PM, Susan Hares <[email-masked]> wrote:
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 7 Apr 2020 13:46:07 +0000

Support.

Best Regards,
Huaimo
________________________________
From: Idr <[email-masked]> on behalf of stefano previdi <[email-masked]>
Sent: Tuesday, April 7, 2020 7:13 AM
To: Susan Hares <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] WG Adoption - draft-li-idr-sr-policy-path-mtu-03.txt - 2 Week WG adoption call (3/30 - 4/13)

I support the adoption.

Thanks.
s.

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-idr-sr-policy-path-mtu%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cd38a5b3c6c3244e6acef08d7dae4be17%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637218548304749830&amp;sdata=gvXnbU7daeeci6FDrRZx94oiB3TrTkQA24A2yphasEM%3D&amp;reserved=0
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cd38a5b3c6c3244e6acef08d7dae4be17%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637218548304749830&amp;sdata=Nx%2FAH%2FmcOwx7V4shDgtq4SU4sNX2w%2F9BKt%2FSBjMplqM%3D&amp;reserved=0

_______________________________________________
Idr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cd38a5b3c6c3244e6acef08d7dae4be17%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637218548304749830&amp;sdata=Nx%2FAH%2FmcOwx7V4shDgtq4SU4sNX2w%2F9BKt%2FSBjMplqM%3D&amp;reserved=0

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 5 Apr 2020 17:50:33 +0800

Suport the adoption.

Since the length of the packet header of SR/SRv6 is not fixed, path mtu carried for the SR policy via BGP can deal with some network deployment problems. 

gongxia
 
From: Susan Hares
Date: 2020-03-30 20:35
To: 'IDR List'

 

 

Cheers, Sue Hares

---

From: Mach Chen <[email-masked]>
Date: Wed, 8 Apr 2020 02:43:10 +0000

Hi,

Support the adoption.

Best regards,
Mach

Cheers, Sue Hares

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 8 Apr 2020 09:05:43 +0000

Hi Ketan,

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

Thanks,
Cheng

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

Hello,

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

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

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.

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.

Thanks,
Ketan

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

Cheers, Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 8 Apr 2020 11:37:16 +0000

Hi Cheng,

Please check inline below.

From: Chengli (Cheng Li) <[email-masked]>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; 'IDR List' <[email-masked]>
Cc: SPRING WG <[email-masked]>
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,
Cheng

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

Hello,

  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?

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.

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

   "

   following algorithm:

      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.

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

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

Cheers, Sue Hares

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 8 Apr 2020 13:27:27 +0000

Support.

Best Regards,
Shunwan

Cheers, Sue Hares

---

From: Aijun Wang <[email-masked]>
Date: Thu, 9 Apr 2020 00:07:56 +0800

Hi, Cheng:
I am considering the following scenarios:
When the size of some packets of one flow are small and do not exceed the PMTU value, they are encapsulated upon the corresponding SR policy and will be transferred according to the appointed path as expected. 
But how about other larger packets within the same flow? Will they be dropped or transferred via other non-SR path? If so, will the SR influence the flow’s jitter?

PMTU for the path is one useful information but I think current draft has not elaborate how to use it in different situations. 

Without SR, we can tell the customer the MTU of the network. But with SR, the network MTU will be changed based on the path length. Considering this, maybe the PMTU that detected by the host will be more convincible?

Aijun Wang
China Telecom

> On Apr 8, 2020, at 17:07, Chengli (Cheng Li) <[email-masked]> wrote:
> 
> 
> Hi Ketan,
>  
> 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?
> 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.
>    “
>    Using the terminology defined in [5], an LSR MUST execute the
>    following algorithm:
>  
>        “
> 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.
> 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?

---

From: Ahmed MostafaSaleh ElSawaf <[email-masked]>
Date: Tue, 7 Apr 2020 10:14:17 +0000

Dears

I believe it is valid use case , I add my voice to support the adoption

The adoption of SR is increase within SP and PMTU is an important and Major topics that should be handled in right way

For below question

The problem statement is clear , and the answer Yes. It is vital requirement to have a right encapsulation for SRv6 without take in the consideration the underneath environment.

No Concern

Thanks

BR
Ahmed El Sawaf

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

Cheers, Sue Hares

The information in this email may contain confidential material and it is intended solely for the addresses. Access to this  email by anyone else is unauthorized. If you are not the intended recipient, please delete the email and destroy any copies of it, any disclosure, copying, distribution is prohibited and may be considered unlawful. Contents of this email and any attachments may be altered, Statement and opinions expressed in this email are those of the sender, and do not necessarily  reflect those of Saudi Telecommunications Company (STC).

---

From: Ahmed MostafaSaleh ElSawaf <[email-masked]>
Date: Thu, 9 Apr 2020 07:04:55 +0000

Dears

For below question

No Concern

Thanks

BR
Ahmed El Sawaf

Cheers, Sue Hares

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 9 Apr 2020 07:58:45 +0000

Hi Aijun,

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

Best regards,
Cheng

From: Aijun Wang [mailto:[email-masked]]
Sent: Thursday, April 9, 2020 12:08 AM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Ketan Talaulikar (ketant) <ketant=[email-masked]>; Susan Hares <[email-masked]>; IDR List <[email-masked]>; SPRING WG <[email-masked]>
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:

[Cheng] The PTMU is the minimum value of the MTU of Links along the path identified by the SID list. Therefore, the value of PMTU describes the largest size of the packet to be sent along the SR path, including the SR overhead. If the received packet is larger than the PMTU – overhead, it will be dropped or fragmented. It is similar to RSVP-TE MPLS. https://tools.ietf.org/html/rfc3209#section-2.6

PMTU for the path is one useful information but I think current draft has not elaborate how to use it in different situations.
[Cheng] Will add text to specify how to handle the value on the ingress node.

Without SR, we can tell the customer the MTU of the network. But with SR, the network MTU will be changed based on the path length. Considering this, maybe the PMTU that detected by the host will be more convincible?
[Cheng] However, the host can not detect the real PMTU of the network, because it can not be aware of the overhead of the SR and others, it will get the minimum value of the Link MTU, but, the really PMTU should be the PMTU – N (SR overhead or other overhead).

Hope I have answered your questions. Thank you again!

Aijun Wang
China Telecom

On Apr 8, 2020, at 17:07, Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ketan,

Thanks,
Cheng

Hello,

   “

   following algorithm:

      this node.
       “

Thanks,
Ketan

Cheers, Sue Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 9 Apr 2020 10:57:16 +0000

Hi Ketan,

Thanks for your reply, please see my reply inline.

Cheng

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Wednesday, April 8, 2020 7:37 PM
To: Chengli (Cheng Li) <[email-masked]>; Susan Hares <[email-masked]>; 'IDR List' <[email-masked]>
Cc: SPRING WG <[email-masked]>
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,

From: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Sent: 08 April 2020 14:36
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; 'IDR List' <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
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,
Cheng

Hello,

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

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

   "

   following algorithm:

      this node.
       "

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

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

Thanks,
Ketan

Thanks,
Ketan

Cheers, Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 9 Apr 2020 11:32:40 +0000

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

Sent: 09 April 2020 16:27

Hi Ketan,

Cheng

To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; 'IDR List' <[email-masked]<mailto:[email-masked]>>

Hi Cheng,

Hi Ketan,

Thanks,
Cheng

Hello,

   "

   following algorithm:

      this node.
       "

Thanks,
Ketan

Thanks,
Ketan

Cheers, Sue Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 9 Apr 2020 14:57:39 +0000

Hi Ketan,

After reading the discussion between you and Cheng, my understanding is that you are converging on the technical parts, and some additional description would help.

As for where such description belongs to, IMO it depends on whether it is about generic path MTU computation and headend manipulation (similar to the RSVP-TE case), or it would introduce additional SR specific behaviors. In the former case, maybe it is fine to add that description into this draft. If it is the latter case, maybe it is suitable to be described in a SPRING document.

Hope this helps.

Best regards,
Jie

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

Hi Cheng,

Thanks,
Ketan

Hi Ketan,

Cheng

Hi Cheng,

Hi Ketan,

Thanks,
Cheng

Hello,

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

   "

   following algorithm:

      this node.
       "

Thanks,
Ketan

Thanks,
Ketan

Cheers, Sue Hares

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 9 Apr 2020 14:59:39 +0000

Hi Sue,

Yes, I support the adoption of this document.

Please find my replies to the questions inline:

Yes, it is a useful feature for SR policy.

Not aware of additional issues.

Yes, it is in the right direction and ready for adoption.

Best regards,
Jie

Cheers, Sue Hares

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 10 Apr 2020 10:13:05 +0000

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

Hi Cheng,

Thanks,
Ketan

Hi Ketan,

Cheng

Hi Cheng,

Hi Ketan,

Thanks,
Cheng

Hello,

   "

   following algorithm:

      this node.
       "

Thanks,
Ketan

Thanks,
Ketan

Cheers, Sue Hares