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

Adrian Farrel <> Fri, 19 February 2021 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E121A3A10E2; Fri, 19 Feb 2021 08:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.001, RCVD_IN_DNSWL_BLOCKED=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 gSrNBoD6Ys6O; Fri, 19 Feb 2021 08:27:39 -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 C4ECE3A10A6; Fri, 19 Feb 2021 08:27:38 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 11JGRPBF023479; Fri, 19 Feb 2021 16:27:35 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 16E0922052; Fri, 19 Feb 2021 16:27:35 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 0B52C22048; Fri, 19 Feb 2021 16:27:35 +0000 (GMT)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 11JGRX41028248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Feb 2021 16:27:34 GMT
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Vishnu Pavan Beeram'" <>, "'TEAS WG'" <>
Cc: "'TEAS WG Chairs'" <>
References: <>
In-Reply-To: <>
Date: Fri, 19 Feb 2021 16:27:33 -0000
Organization: Old Dog Consulting
Message-ID: <085101d706dc$20a53a30$61efae90$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0852_01D706DC.20A699C0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHHdf4jTtE51mkE03j58GYCUGrFoqp+qBBQ
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--10.524-10.0-31-10
X-imss-scan-details: No--10.524-10.0-31-10
X-TMASE-Result: 10--10.524400-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtFfsB4HYR80ZnFPUrVDm6jtiRPU6vvejXLVH+m1hZHwLqn9 D3t+sZBoeG/tRkLoURc4P2Ei2oO+NPcqbABI0A3bCbXjsXAtrYqhea/0QyPTC0oMqYzZgxDrnLx Qb6qDSvsAneoww91EyQ+wyJIhO/VVXT9R4ooX4QHece0aRiX9WhpxmKWTfsQIy5JfHvVu9ItYx/ xgeIVse/Do6JCnGcJGcIMzCx3WWG28+Qw9PrZG9WXaK3KHx/xpy0Q+dW8+UWR0b9gfOpwitfbpI Tsbsw2IeB6/Wp7PeVET3qD7eKafuclAYw8EIjOi9txS2GzA7H+pvf+jmz45w5i8S0YRBJYaa7kO XtHfmxxpbcYIIdyBJliv/vFtB9P72wdzMkws8ae6iJsmkdGsWSY6ALX8FNLOPLEtHZJkhoxz+NW kRQjaNq4EpK+0MtIzbcKMoK0VVcDkEToQJUIf850Oc+z2aaHKQaH4g4P6OtZv0qcu7SRm5YuKNR D4lgYXkLJiSUsnPAwlMcFNu44sG3Z59GlLct/lYKm742WlIN5ReWnUUdhI9aRea8wUAdQ6h8Uzj uoP0V7G3mclzQaxV+aZCj8NRE4FXYxwRk37KZtHKdPCX1liHkpFpc3bJiMe26nR8RrBX2lHIZOi mSs2+ur3YZkSGkoBPk+OpnRLoHFcc5kLM5A5lLdHEv7sR/OwguwtqyXlE6GNJ2ckLRg2Ue6gy0w Dg4kLz7cLlKExWWHE/u82IWeSk6TMcFF0yTXMA9lly13c/gEpA2ExuipmWtctGlxeXl/oyyEGYR WMydrLsi9cYnD04/fL1vPD/5IawtOA1g8gH4WeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7uqrK9Zq3Uhtl3182k4X2JPRnQtyGfN/Qi69YDC/qPMSlM3ETdh663ZtuBppyS txBuRoP6Xrc5mlEMztUXF06rhqN7rfrJyjeFP00nKmGrQ60=
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: Fri, 19 Feb 2021 16:27:42 -0000



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