Re: [mpls] Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte

Alexander Okonnikov <> Mon, 13 May 2019 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3822912003F; Mon, 13 May 2019 08:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OaDeGnBPwlqr; Mon, 13 May 2019 08:31:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6077F120104; Mon, 13 May 2019 08:31:39 -0700 (PDT)
Received: by with SMTP id d12so15765461wrm.8; Mon, 13 May 2019 08:31:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nqcF3BeHyYVRkEWdC0fgE79kghuXReV5VNaHN7C6KqM=; b=BY9bU0R9xXhRqBGHk7EjXIiR/k68qx6Nbhi27nExs9DLj6SGj5kfWg7V5lFGrXqD8u VXENkSOIyiwm0ABvBe3APfjqucXuPPsfodL03M/Zx7kfQE1zWcTxW1V8Y7cg+OjtbGiz i4Hm6t5PV+hQ2w4eY/bBVqmAEhCaWZz8ywmuQq6XvRV2v4NdbalV1bS9tNu/AFCncdAI C3p0O9NeDKsF0srC9SwumsWia8nAlVVJ8WFUkR1ZEqMdJtjdjb921m9aNTbrViFz3DnJ w7u/1eQDu6ro6KvugQjF4TgC0cB41J06VN44XYht5iQlGb8NAK3MZRxAku5coO1Ay6Bm 4GOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nqcF3BeHyYVRkEWdC0fgE79kghuXReV5VNaHN7C6KqM=; b=bFcTcMPP/MzsRmtay2HIEbsMKJDbMkBctWoek5xY63Cp/x36WJohyI0xf/I37z09AF TDYrI2FFG5uLplyjJDNagpvL+c7HPgDH5v3rqrYW4Ie2rvWC3i5ZeSq344K8CN1f1GA+ ZXXEXFMLUvpw8gNeE7MktwhvIb2Y0FdjbDv1YTcuOR++Uub6s1KLPhcTudLp9xdHrBTA 33TGeZNyIFFnYSTEOQsH/BA29Xc9BQAxUMDl6e9esJtPhAGP6IhyiLTCJXKZVITQ59xg FDmt0AIvbLmLDxb5gPVts3WU7fkGSnfifB7rPgjYWmKKAyAi5DdK33/dt6MnJZBXw7oB u20w==
X-Gm-Message-State: APjAAAWsIbYu+UA6zQutto7obNTJy8yssslYLValX2+NFvYq6HRK00Fz fRtG/wBzy/NeawmJ/dOsd3M=
X-Google-Smtp-Source: APXvYqwfYy+RUQHlflDly+dyujeV1I8fYUf+DfaE5e+H1RSVPp4mzwDvVEgYyv2zyRdlUjMFXk3dHA==
X-Received: by 2002:adf:c98f:: with SMTP id f15mr18578786wrh.279.1557761497828; Mon, 13 May 2019 08:31:37 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id s3sm23639066wre.97.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 08:31:37 -0700 (PDT)
From: Alexander Okonnikov <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_686D648D-B35C-471E-9D04-9D5055D0DA63"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 13 May 2019 18:31:33 +0300
In-Reply-To: <>
Cc: Markus Jork <>, "" <>, "" <>, "" <>
To: "Mike Taillon (mtaillon)" <>
References: <LEJPR01MB0377540FAEC1EE9448740E78983A0@LEJPR01MB0377.DEUPRD01.PROD.OUTLOOK.DE> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-summary-frr-rsvpte
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2019 15:31:46 -0000

Hi Mike,

Do you mean the gap in merging of Path messages by MP in part of choosing ADSPEC of protected LSP rather than merging ADSPECs (choosing minimal MTU, particularly)? Oh, agree. Though if we would assume that MP did perform merging of ADSPEC (and probably other objects where applicable), there would be problem with signaling backup LSP MTU to MP after failure.

I agree that guaranting enough MTU size on all links in the network is good practice, but in reality it not always could be provided, or could be provided with significant penalty on manageability.

Per my understanding, reliable solution would be for head-end:

1) to specify minimum LSP MTU as a constraint (like resource affinities, BW, etc.) for CSPF and take link MTUs from TEDB into consideration, and

2) to signal to downstream LSRs minimum LSP MTU (by virtue of SENDER_TSPEC, like BW), such that PLRs would be able to make decision about availability of bypass tunnels, which can accomodate requested MTU.

Thank you!

> 9 мая 2019 г., в 15:28, Mike Taillon (mtaillon) <> написал(а):
> Hi Alexander,
> I beleive MTU handling post FRR is not covered in base RFC4090 and is therefore an existing gap.
> It kinda defeats the purpose if headend needs to adjust MTU after FRR to prevent drops… and would presume most deployments assume that backup MTU can accomandate MTU of primary LSP (plus any added MP labels). 
> Issue deserves discussion, but think its out of scope from this document.
> -mike
>> On May 7, 2019, at 4:54 PM, Alexander Okonnikov < <>> wrote:
>> Hi authors,
>> As far as Summary FRR LSPs are not being signaled via Path messages over bypass tunnel after failure, information on head-ends about actual path MTU of protected LSPs can be corrupted. For example, path MTU of protected LSP is 1500 bytes (provided that ADSPEC is used), and path MTU of bypass tunnel is, for example, 1500 bytes. As far as Path messages for protected LSPs are not being sent over bypass tunnel, MP will use ADSPEC received in Path messages of those protected LSPs previoulsy (before they have been rerouted onto bypass tunnel), i.e. 1500 bytes in place of 1496 bytes. To avoid this problem PLR would have to signal path MTU of its bypass tunnel in B-SFRR-Active object (alternatively, MP could inherit this value from ADSPEC of PSB of the bypass tunnel), and 2) MP would have to choose minimal of MTU values from ADSPEC objects while merging Summary FRR protected LSP. But, even in this case MP will have to generate trigger Path messages (with updated ADSPEC) for protected LSPs and then, after receiving Resv messages with updated FLOWSPEC, send them to PLR. I.e. summary refresh in MP->PLR direction with high probability will be inapplicable, due to trigger messages.
>> Thanks.
>>> 7 мая 2019 г., в 23:46, Markus Jork < <>> написал(а):
>>> As a co-author,  I believe this document is ready for publication.
>>> -Markus
>>>> On Apr 30, 2019, at 4:33 AM, <> wrote:
>>>> Working Group,
>>>> This mail initiates the two weeks working group last call on draft-ietf-mpls-summary-frr-rsvpte which is considered mature and ready for a final working group review.
>>>> Please read this document if you haven't read the most recent version yet, and send your comments to the mpls wg mailing list ( <>), not later than 17th of May.
>>>> There is one IPR disclosure against draft-ietf-mpls-summary-frr-rsvpte
>>>> This working group last call ends May 17th, 2019 (there is at least in some countries a public holiday this week, therefore the call is a bit longer than usual).
>>>> Best regards
>>>> Nic
>>> _______________________________________________
>>> mpls mailing list
>>> <>
>>> <>