Re: [Idr] [spring] I-D Action: draft-li-idr-sr-policy-path-mtu-01.txt

Hi Robert,

Thanks for your comments, and happy new year!

Sorry for my delay, please see my reply inline.

Best Regards,
Cheng

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, December 27, 2018 6:31 PM
To: idr@ietf. org <idr@ietf.org>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] I-D Action: draft-li-idr-sr-policy-path-mtu-01.txt

Authors,

SR policy draft aims to add new SAFI to distribute SR policies aka paths via BGP.

However in SR "path" really means single or set of anchor points packets would need to traverse to meet required policies, It makes no assumption about nodes or links which are not on the SR node list and are places between SR nodes.
[Cheng]Yes, you are right. An SR path means a set of endpoint nodes would need to traverse to meet required policies.

Currently in our document, we always assume that the controller calculates the path MTU based on BGP/IGP data and gives it to the node.
We may need to state that this would be “the best” approximate value as per the information at the controller where controller can consider the path MTU of the best paths (in case of loose hops and lower value in case of ECMP(?)).

This approximate PMTU is useful in SR TE scenarios.
For SR BE,  the PMTU of the IGP shortest forwarding path between endpoint nodes can be calculated by the controller as long as the Link MTUs can be collected, so the controller can get the PMTU of the SR BE path as well.

Your draft (while perhaps theoretically useful) introduces completely new dynamics to the SR policy proposal as now the originator of SR policies must track atomic link MTUs on how to get from any potential recipient of such policies to given list of anchor nodes (SR nodes).
[Cheng] In order to make sure that the PMTU depict the real MTU of the path, it should be collected and updated in time.

Even encoding wise the draft as proposed does not meet the stated requirements as it mistakenly assumes  that MTU to reach given set of policies would be identical from any ingress node.
[Cheng] Sorry, I don't really understand this point, identical from any ingress node?
Do you mean SR Policy[E,F,G] can be configured at the headend node A, B and C respectively, then the MTU of [E,F,G] is wrongly configured as identical at different ingress A, B and C?

Actually, in this case, the PMTUs are different among these SR policies, since they are different SR policies.
An SR policy is identified by <headend, color, endpoint>. The PMTU maybe different since the link MTU between the headend node and the first endpoint node may be different.

Last - in practice there is no way for the controller or any other oracle to know the real MTU since many networks uses emulated circuits as native links and the real MTU not only may change every delta time, but is only detectable by data plane end to end probes.
[Cheng] Yes, there are some scenarios like that. But most of the cases, the MTU should be stable.
Also, E2E probing can be used to get the PMTU. We aim to set the PMTU in the SR policy while any useful mechanism to get the MPTU can be used for sure.

We can also allow the probe/controller/SR-Ingress to use data plane path MTU discovery technique instead of ‘best’ approximate value with a flag stating the source of this information as approximate or measured.

Thanks again!

With that I think this proposal should not be added to SR policy document in the current form.

Kind regards,
Robert.

On Thu, Dec 27, 2018 at 9:18 AM <internet-drafts@ietf.org<mailto:internet-drafts@ietf..org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Segment Routing Path MTU in BGP
        Authors         : Cheng Li
                          Zhenbin Li
        Filename        : draft-li-idr-sr-policy-path-mtu-01.txt
        Pages           : 7
        Date            : 2018-12-27

Abstract:
   Segment routing is a source routing paradigm that explicitly
   indicates the forwarding path for packets at the ingress node.  An SR
   policy is a set of candidate SR paths consisting of one or more
   segment lists with necessary path attributes.  However, the path
   maximum transmission unit (MTU) information for SR path is not
   available in the SR policy since the SR does not require signaling.
   This document defines extensions to BGP to distribute path MTU
   information within SR policies.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-li-idr-sr-policy-path-mtu/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-li-idr-sr-policy-path-mtu-01
https://datatracker.ietf.org/doc/html/draft-li-idr-sr-policy-path-mtu-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-li-idr-sr-policy-path-mtu-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt