Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05

Jeong-dong Ryoo <ryoo@etri.re.kr> Thu, 25 February 2021 06:54 UTC

Return-Path: <ryoo@etri.re.kr>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71273A1449 for <teas@ietfa.amsl.com>; Wed, 24 Feb 2021 22:54:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99bAH9m0n09h for <teas@ietfa.amsl.com>; Wed, 24 Feb 2021 22:54:37 -0800 (PST)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF81B3A1448 for <teas@ietf.org>; Wed, 24 Feb 2021 22:54:36 -0800 (PST)
Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 25 Feb 2021 15:54:29 +0900
X-Original-SENDERIP: 211.180.235.152
X-Original-MAILFROM: ryoo@etri.re.kr
X-Original-RCPTTO: teas@ietf.org
Received: from [10.162.225.103] (HELO send001.gov-dooray.com) ([10.162.225.103]) by send001-relay.gov-dooray.com with SMTP id fe141cd9603749a8; Thu, 25 Feb 2021 15:54:32 +0900
DKIM-Signature: a=rsa-sha256; b=Ls2D55ZFcVL8z/6qsYwaRHrxYAIaloRfYqtRbs4tu5UEJ0P6IWvqhp0AjdZmfXaw7NS334bgUJ qcqgqwX6pR90XeaZwVmz1CrqoZj1cMm8rHme7ZGpbli3qzRBwvP5TfRO3rfvhqULm+tTZAmEdoI2 pm+jVMSJjPyDCCqjEvJ07BGUG+n4eeceaH3PobCb7uxh/z7d16xxbavxbS3Xj6pODuk/tvtNGfpU hcViQldbpgHq/mQI8spwn1PAy5/oC19mluzUnlC/qlXWDQXILxbWj8v8VpBLt6/NvMHLKGWBhd9g G3kMbIU+sM0fwQ+3888Mnv3q6rTcJIzCV5JDrA6w==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=4GXB7KX4UC5OXoqnIX/NJD3NiwmJez8E4pdGL8eQfhs=; h=From:To:Subject:Message-ID;
Dooray-Meta-Signature: feaOlLeG0QPvh4HBzTJW1nUL/Z9TO8PGBWUFB6dPIGtl9PQQVL+zR 4MVurMPdZau6s915o7W1VucUCd+W2Cmmzb1Yz6hTpO6WkJGj6mVBaiigzlMafiLUfPLuVCEGghQD 6h4WyFM4T6X/sHqnf2tKykA6SRHVU9TsMbFTbRePlWgOfqN6u5M3J1tLyKOsroCL1EU0fWRwPWTw /MVbzViS4BmrbVxARefzdb54V3VKx2g+kjelb3zJouvP7C4v1j5z+3M2u7qgRe8+G5UPfCl1v7M8 tD/mX8oZc3SDFIaylfOI+31yegaRQQbkWIWeMyAUhL1iQpWQiSDNLpHio79vA==
Received: from [129.254.197.129] (HELO 129.254.197.129) ([129.254.197.129]) by send001.gov-dooray.com with SMTP id 693bbd6a603749a6; Thu, 25 Feb 2021 15:54:30 +0900
From: Jeong-dong Ryoo <ryoo@etri.re.kr>
To: 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>, 'TEAS WG' <teas@ietf.org>, adrian@olddog.co.uk
Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>
Message-ID: <mfgp5872mlg9.mfgp5873ccva.g1@dooray.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_414530_1329388093.1614236068334"
X-Dsn-Request: true
X-Dooray-Agent: mail-api
X-Dooray-Mail-Id: 2952215757847958553
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
Sender: ryoo@etri.re.kr
Date: Thu, 25 Feb 2021 15:54:29 +0900 (KST)
References: <CA+YzgTtALaE321eNnoMXmP00ZV3m2N9nCFfAy2SCxip10hysaA@mail.gmail.com> <085101d706dc$20a53a30$61efae90$@olddog.co.uk>
In-Reply-To: <085101d706dc$20a53a30$61efae90$@olddog.co.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/0yL6Lu8HrqQzJwa5jqGRQpCvbNg>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2021 06:54:42 -0000

Dear Adrian,

Thank you for your support and comments.

You have illustrated an important example, which suggests us to mandate the use of the Notify message. &nbsp;It can further demonstrate how the priority values of services can influence the number of protected services. For example, the highest priority is given to the middle LSP, the number of protected services would be only one with or without the Notify message. &nbsp;

For higher network availability and throughput, we need to protect as many services as possible even under multiple simultaneous demands. I and co-authors have initially thought the Notify message can be used selectively to optimize network utilization, but your point on implementation is quite valid. Therefore, I would like to propose to use "MUST" instead of "MAY" for the Notify message. If I don't see any objection to this change, I will modify the text associated with the Notify message reflecting the points you made.&nbsp;

All other comments you listed as "minor" and "nits" should also be reflected in the next revision.

Best regards,

Jeong-dong





-----Original Message-----
From: "Adrian Farrel" &lt;adrian@olddog.co.uk&gtk&gt;
To: "'Vishnu Pavan Beeram'" &lt;vishnupavan@gmail.com&gtm&gt;; "'TEAS WG'" &lt;teas@ietf.org&gtg&gt;;
Cc: "'TEAS WG Chairs'" &lt;teas-chairs@ietf.org&gtg&gt;;
Sent: 2021-02-20 (토) 01:27:53 (UTC+09:00)
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05

Hi,
&nbsp;
I'll get my comments in early.
&nbsp;
Thanks to the authors for a short and readable document. The mechanisms described seem robust.
&nbsp;
I previously had questions about how this draft worked, and the authors handled them well with explanations to me, and clarifications in the draft.
&nbsp;
I have just re-read the whole document and I support this last call. The document is very, very nearly ready for publication as an RFC.
&nbsp;
There is one issue about overlapping preemption that I would like to discuss, and a couple of minor points to look at.
&nbsp;
There are also some tiny nits that I suppose we should fix before moving the draft onward, but I don't think they change my support for the last call.
&nbsp;
Best,
Adrian
&nbsp;
=== Question
&nbsp;
In section 4, I think that preemption can get ugly :-(
&nbsp;
Consider this topology (turn on non-proportional font!)
&nbsp;
I have only shown the protecting LSPs. The normal, primary LSPs are not
shown
&nbsp;
&nbsp;
A &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; D
&nbsp;\ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /
&nbsp; \ &nbsp; &nbsp; &nbsp; &nbsp; /
E--F---G---H
&nbsp; &nbsp; &nbsp; &nbsp; \
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\
I----J----K---L---M
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;N
&nbsp;
There are three protecting LSPs:
A-F-G-H-D
E-F-G-K-L-M
I-J-K-L-N
Let's assume they have SMP priorities 3, 2, and 1 respectively.
Let's also assume that a fault (or multiple faults) affect the primary&nbsp;
LSPs so that all three protecting LSPs are activated.
&nbsp;
Clearly, once everything has settled down, I-J-K-L-N will be carrying
traffic. The other two LSPs will have been preempted. However, it is
also possible for A-F-G-H-D to carry traffic.
&nbsp;
For this to work, there has to be a lot more coordination among the&nbsp;
LSPs. The Notify message that is marked as "MAY" in section 4 when K-L
is preempted would be necessary, and E would have to "withdraw" its
demand on the resources at F-G, and then F would also have to send a
Notify to A.
&nbsp;
So the question for the authors is:
&nbsp; &nbsp;Do we want to support this topology with its multiple overlaps?
If we don't, that's OK, but perhaps we need to make it clear.
If we do, then perhaps the use of "MAY" for the Notify messages and
subsequent behavior has to be tightened to "MUST".
&nbsp;
For what it is worth, I don't think K can know about the shared resource
on F-G without some additional signaling. So we could have a flag in the
signaling for E-F-G-K-L-M that requires K to send a Notify. Or we could
always require K to send the Notify.
&nbsp;
&nbsp;
These are then two subsidiary points that may go away depending on the
resolution of my question, above:
&nbsp;
a. When you use "MAY" you need to give some guidance to the implementer
&nbsp; &nbsp;on how they choose whether to do the thing or not. Sometimes it is
&nbsp; &nbsp;"subject to local/global configuration". Sometimes it is, "in order
&nbsp; &nbsp;to optimise foo". But otherwise, the implementer will shrug and not
&nbsp; &nbsp;write any code, so your "MAY" will turn into "MUST NOT"!
&nbsp;
b. I assume that the quality of the MAY for sending a Notify to say that
&nbsp; &nbsp;resources have come available again is at least as strong as for
&nbsp; &nbsp;sending a Notify to say that the resources are unavailable. Otherwise
&nbsp; &nbsp;you'll end up, over time, with all resources assumed to be&nbsp;
&nbsp; &nbsp;unavailable.
&nbsp;
=== Minor
&nbsp;
5.3
I think that you also need to say how an ingress decides which&nbsp;
preemption priority to set on an LSP. It is probably configuration, or
part of the request made to the ingress to set up the LSP. The point is,
it is not left to the ingress implementation to pick a number at random.
&nbsp;
---
&nbsp;
7. I wonder whether you'll get away with section 7. I think that you&nbsp;
have introduced an additional "fragility" into the network. It may now
be possible to cause disruption to traffic on one protection LSP by
targeting a link used by the primary path of another, higher priority
LSP somewhere completely different in the network.
&nbsp;
I don't believe that there is anything you should do about this in the
protocol, but I think you should flag this attack vector and note that
it makes two things important:
- use of security mechanisms as discussed in RFC 4872
- preservation of privacy of information about protection paths within
&nbsp; the network
&nbsp;
=== Nits
&nbsp;
1.
s/(SMR) mechanism./(SMR) mechanisms./
s/an explicit restoration signaling/explicit restoration signaling/
s/it via the control plane/it via control plane/
---
2.
The pointers to terminology used in [RFC4872] and [RFC4426] are good.
I wondered whether RFC 6372 might also be useful background or not.
---
3. and 4.4
s/a SMP/an SMP/
---
3.
s/e.g./e.g.,/
s/control plan signaling/control plane signaling/
s/operation while/operation, while/
---
4.
Just for complete clarity...
OLD
&nbsp; &nbsp;Similar to SMR, a new LSP Protection Type of
&nbsp; &nbsp;the secondary LSP is defined as "Shared Mesh Protection" (see
&nbsp; &nbsp;Section 5.1) to allow resource sharing along nodes E, F, and G.
NEW
&nbsp; &nbsp;Similar to SMR, this document defines a new LSP Protection Type of
&nbsp; &nbsp;the secondary LSP as "Shared Mesh Protection" (see
&nbsp; &nbsp;Section 5.1) to allow resource sharing along nodes E, F, and G.
END
---
4.
s/This would avoid/This avoids/
---
&nbsp;
From:&nbsp;Teas &lt;teas-bounces@ietf.org&gtg&gt; On Behalf Of&nbsp;Vishnu Pavan BeeramSent: 19 February 2021 12:50To: TEAS WG &lt;teas@ietf.org&gt;Ccmp;gt;Cc: TEAS WG Chairs &lt;teas-chairs@ietf.org&gt;Subject;Subject: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05

&nbsp;
All,
This starts a two-week working group last call on draft-ietf-teas-gmpls-signaling-smp-05

&nbsp;

The working group last call ends on March 4th 2021.Please send your comments to the teas mailing list.Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors.Thank you,TEAS Chairs


_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas