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

Adrian Farrel <> Thu, 25 February 2021 10:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D69863A1729; Thu, 25 Feb 2021 02:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AAm_O-wqFPS6; Thu, 25 Feb 2021 02:20:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 643D33A1725; Thu, 25 Feb 2021 02:20:19 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 11PAK9jw001632; Thu, 25 Feb 2021 10:20:09 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 58E472204A; Thu, 25 Feb 2021 10:20:09 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 40F4222044; Thu, 25 Feb 2021 10:20:09 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 11PAK7Dw031913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Feb 2021 10:20:08 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: <>, "'Vishnu Pavan Beeram'" <>, "'TEAS WG'" <>
Cc: "'TEAS WG Chairs'" <>
References: <> <085101d706dc$20a53a30$61efae90$> <>
In-Reply-To: <>
Date: Thu, 25 Feb 2021 10:20:07 -0000
Organization: Old Dog Consulting
Message-ID: <068001d70b5f$cb1700c0$61450240$>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0681_01D70B5F.CB18FC90"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHHdf4jTtE51mkE03j58GYCUGrFogKvng9TAf6v9cmqYmCVIA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--10.509-10.0-31-10
X-imss-scan-details: No--10.509-10.0-31-10
X-TMASE-Result: 10--10.508700-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMxfsB4HYR80ZnFPUrVDm6jtc9pwoOhfS8+3CLdtdG1oCJ2r 72g43+6yge3RWI4Rcf4T3LYgm7MNcba2Vh2jQ2eEhL9NX2TqmkClAfiiC1VA/TY85u6LykAGtPZ 0go2hmmllh5NeXb2p3i3L7tYza8bIcwUZzneGng1usn2BWc6xnUpFpc3bJiMeIwfkkTESbiRyoN 2QiJtl0T0IvSaRecrxF2c/3jdGfG3AeJC9YLCwAbzgL/eLACDEQ37rdi3NWIde9JbKiTZnHqTzD EJ69wpVVL7hYtAXppZD/i1pae2iz0CT547EIg6fzNY33yIEF4ad2Wz0X3OaLW82zvsXichawbXw AnjBu525+UgmMi+gz/l3voZgX7y+V3UOf7o5l21COHkvZleP7Cv2BWU4g3/qk7MocNSj6pDom3P KoTfCKNW3enbVLbrnQNUOvn+6fK9ypcLcRNCRIvlNbKGx4Q7UV447DNvw38YhXy0Vy8CS1IR4RL K5G1ih6BFoR+bbormTYASkbHiY/g4Txrw5BhN4tRoHk3L5VJxceVBIhfwO9RyNr44gj8j7/8AbF rcBTUDrKSBTkozzvrVusIDkny6yysDdeofVK83C0TXpqtexIibiV/S36CI4RjNrjV0arFLeengL Zqtq8JbA99cNfiAI8Y6lZf/WV2/1HKFnt7/e8iTc3NdTt+Z6NkBLQ/OKPBDjMJwxZYqyJouKNRD 4lgYXkLJiSUsnPAy0yQJ9dfbam98RW/BeXJUkLTHwnYOikQ2m7EUWk2jS0Y0jIdnB7VAWqIKNo5 gIFrNvv99WAopBU1s2YcxnzNBgzhaVsg5k9zA0i6L0DcfAACHmjNSy4BIir10pknZXGJqb4iDlO 9ygjhvhAObZuuUtU6baA36eiawgbhiVsIMQK9XvcOE839ggTpnBgfYFMcTLPxIs5W99W+1Stwl8 PVOmTiXJHM0Xh+lSStp4TurTLRxzXcXw4zfcyvUY8mCG4aFahPs3swPiDiJmVvIIugDD
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Feb 2021 10:20:25 -0000

Hi Jeong-dong,


Thanks for thinking about my comments. Looks like you have them in hand.





From: <> 
Sent: 25 February 2021 06:54
To: 'Vishnu Pavan Beeram' <>om>; 'TEAS WG' <>rg>;
Cc: 'TEAS WG Chairs' <>
Subject: RE: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05


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


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. 


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


Best regards,








-----Original Message-----

From: "Adrian Farrel" <>

To: "'Vishnu Pavan Beeram'" <>om>; "'TEAS WG'" <>rg>;

Cc: "'TEAS WG Chairs'" <>rg>;

Sent: 2021-02-20 (토) 01:27:53 (UTC+09:00)

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




I'll get my comments in early.


Thanks to the authors for a short and readable document. The mechanisms described seem robust.


I previously had questions about how this draft worked, and the authors handled them well with explanations to me, and clarifications in the draft.


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.


There is one issue about overlapping preemption that I would like to discuss, and a couple of minor points to look at.


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.





=== Question


In section 4, I think that preemption can get ugly :-(


Consider this topology (turn on non-proportional font!)


I have only shown the protecting LSPs. The normal, primary LSPs are not




A             D

 \           /

  \         /









There are three protecting LSPs:




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 

LSPs so that all three protecting LSPs are activated.


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.


For this to work, there has to be a lot more coordination among the 

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.


So the question for the authors is:

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


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.



These are then two subsidiary points that may go away depending on the

resolution of my question, above:


a. When you use "MAY" you need to give some guidance to the implementer

   on how they choose whether to do the thing or not. Sometimes it is

   "subject to local/global configuration". Sometimes it is, "in order

   to optimise foo". But otherwise, the implementer will shrug and not

   write any code, so your "MAY" will turn into "MUST NOT"!


b. I assume that the quality of the MAY for sending a Notify to say that

   resources have come available again is at least as strong as for

   sending a Notify to say that the resources are unavailable. Otherwise

   you'll end up, over time, with all resources assumed to be 



=== Minor



I think that you also need to say how an ingress decides which 

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.




7. I wonder whether you'll get away with section 7. I think that you 

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.


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

  the network


=== Nits



s/(SMR) mechanism./(SMR) mechanisms./

s/an explicit restoration signaling/explicit restoration signaling/

s/it via the control plane/it via control plane/



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/




s/control plan signaling/control plane signaling/

s/operation while/operation, while/



Just for complete clarity...


   Similar to SMR, a new LSP Protection Type of

   the secondary LSP is defined as "Shared Mesh Protection" (see

   Section 5.1) to allow resource sharing along nodes E, F, and G.


   Similar to SMR, this document defines a new LSP Protection Type of

   the secondary LSP as "Shared Mesh Protection" (see

   Section 5.1) to allow resource sharing along nodes E, F, and G.




s/This would avoid/This avoids/



From: Teas <> On Behalf Of Vishnu Pavan Beeram
Sent: 19 February 2021 12:50
To: TEAS WG <>
Cc: TEAS WG Chairs <>
Subject: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05



This starts a two-week working group last call on draft-ietf-teas-gmpls-signaling-smp-05


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