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

Robert Raszuk <> Thu, 27 December 2018 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7342128CF3 for <>; Thu, 27 Dec 2018 02:31:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id udSpcUr-cT5U for <>; Thu, 27 Dec 2018 02:31:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C318212950A for <>; Thu, 27 Dec 2018 02:31:30 -0800 (PST)
Received: by with SMTP id n12so10588717qkh.11 for <>; Thu, 27 Dec 2018 02:31:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yrXI89hIKl24GLD3ZjpPQ1nYmE7OexK3gYRbqfgYObA=; b=NkBJBknOKsXqJq+FhV3ipsWSuwlOj8QjbQnbq0HhxtjL3sN5ZwnlB/Q3fN59kSIvu0 zF+zNeNV8IONhVE014sQuAPnJ07qwOYmDb53sXlZ/9RwlAZ/wAj8pHwfbLK+BMSOOhyA aghk0S5Mm0dK6U00K9uZVqPLIaZLIKfrFwZhWVMaoIdlh6Fwmof8fripgMj9EA0Hj7Th GSsAj23XIwtOS+yqpksHalZwdsMQS6n9rIw4Nq5/NlYqCOHVihSuiwWL3/lRCkg+vwNY /WzwVn+Imh2NxGIbJfT7nz13ShIqygSXfdjBJEFBzeNJoR/bEYt7PRx7OIisjNK2YeAK rIGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yrXI89hIKl24GLD3ZjpPQ1nYmE7OexK3gYRbqfgYObA=; b=smwSelVm73roTOE2MPglzwFjEbXfhJyaYQqbNmvEMpLf5z+fVZBoIiTohN5oZ0+zk1 OCmHn+N1SdVUashHFvkFc7ktTtgTg645Kv1SYi52EOxLt/zlwoDSmzWm/1E+/AIBojbf cg4+xg6FcMlzG1uCKlSSlLg7u4v/rrUcwjn3WC4l4NbXYGTLcnNGBOXe5ae/ALjIL7Ab J/fOs9fe725RN29afx0h1iF9cy83sMiB1kiasbzjTB2Uu061dshe8T/Wreaz3LGJKLiK dcULQdxMC5YOZjimwEzDzG++kI9wpTyUMK+WsVmuDt+DHYiNwgwgzwuimoymgoTGEe5C d7RA==
X-Gm-Message-State: AJcUukdXox2DGSHY2bqUZHbgnpC8mdraWqpbmkVPn/3MuurR6loDcxVl oiezXmzrbSM/cB09AazocJ86s6xHZyJesZFxNWTplKqS
X-Google-Smtp-Source: ALg8bN7oPe/MCIqx/Gk2JokEWSjQOCkFJvDJ0hCJ35n6xeFPB3R77JZXkKIdsXrWLonyRzx53IA9s9hGC0a4/8QnWso=
X-Received: by 2002:a37:6749:: with SMTP id b70mr20739009qkc.41.1545906689476; Thu, 27 Dec 2018 02:31:29 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 27 Dec 2018 11:31:20 +0100
Message-ID: <>
To: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000152135057dfe73a0"
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-li-idr-sr-policy-path-mtu-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Dec 2018 10:31:34 -0000


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.

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

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.

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.

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

Kind regards,

On Thu, Dec 27, 2018 at 9:18 AM <> 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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or