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

[Italo Busi <[e-mail]>]

Jeong-dong, Adrian,

Thanks for the review, comments and proposed resolution

I agree with the proposal to change the ‘MAY’ with a ‘MUST’

I am wondering whether a similar ‘’MUST’ requirement should also be specified to cover the case where the K-L fails

My 2 cents

Italo

From: Adrian Farrel [mailto:[e-mail]]
Sent: giovedì 25 febbraio 2021 11:20
To: [e-mail]; 'Vishnu Pavan Beeram' <[e-mail]>; 'TEAS WG' <[e-mail]>
Cc: 'TEAS WG Chairs' <[e-mail]>
Subject: Re: [Teas] WG Last Call: draft-ietf-teas-gmpls-signaling-smp-05

Hi Jeong-dong,

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

Best,
Adrian

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: 25 February 2021 06:54
To: 'Vishnu Pavan Beeram' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'TEAS WG Chairs' <[e-mail]<mailto:[e-mail]>>
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,

Jeong-dong





-----Original Message-----
From: "Adrian Farrel" <[e-mail]<mailto:[e-mail]>>
To: "'Vishnu Pavan Beeram'" <[e-mail]<mailto:[e-mail]>>; "'TEAS WG'" <[e-mail]<mailto:[e-mail]>>;
Cc: "'TEAS WG Chairs'" <[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Vishnu Pavan Beeram
Sent: 19 February 2021 12:50
To: TEAS WG <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG Chairs <[e-mail]<mailto:[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]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/teas
[Image removed by sender.]