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

[Jeong-dong Ryoo <[e-mail]>]

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,

Jeong-dong





-----Original Message-----
From: "Adrian Farrel" <[e-mail]>
To: "'Vishnu Pavan Beeram'" <[e-mail]>; "'TEAS WG'" <[e-mail]>;
Cc: "'TEAS WG Chairs'" <[e-mail]>;
Sent: 2021-02-20 (토) 01:27:53 (UTC+09:00)
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05

Hi,
 
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.
 
Best,
Adrian
 
=== 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
shown
 
 
A             D
 \           /
  \         /
E--F---G---H
        \
         \
I----J----K---L---M
               \
                \
                 N
 
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 
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 
   unavailable.
 
=== Minor
 
5.3
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
 
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
   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.
NEW
   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.
END
---
4.
s/This would avoid/This avoids/
---
 
From: Teas <[e-mail]> On Behalf Of Vishnu Pavan BeeramSent: 19 February 2021 12:50To: TEAS WG <[e-mail]>Cc: TEAS WG Chairs <[e-mail]>Subject: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05

 
All,
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
[e-mail]
https://www.ietf.org/mailman/listinfo/teas