Re: [Teas] Preemption priority in GMPLS signaling for SMP

[Adrian Farrel <[e-mail]>]

Thanks for this answer, Joeng-dong.

 

As I understand it, when SMP protection LSPs are set up they may “share” resources. That is, they do not compete for resources and so the Setup and Holding priorities don’t apply to how they interact with each other. 

 

Do the protection LSPs still compete with other LSPs? 

 

Assume a link with 1 unit of bandwidth, and 3 LSPs that want to use it. Two are SMP protection LSPs at setup=holding=3, and one is a normal LSP at setup=holding=6. Then the normal LSP would be pre-empted (or fail to set up), but the two SMP protection LSPs would be set up “sharing” the resource.

 

You could use the holding priority to distinguish between the SMP protection LSPs. In my example you could have:

SMP protection LSP-A setup=3 holding=3

SMP protection LSP-B setup=3 holding=2

Normal LSP-C setup=holding=6

Then, LSP-C would be pre-empted (or fail to set up) while LSP-A and LSP-B would be set up sharing the resource.

But when there was a need to use the protection LSPs, LSP-B would have priority over LSP-A.

 

I think I am saying that you *could* achieve what you want using the exiting fields. I’m not actually opposed to you introducing a new priority field, just observing that you might not need to.

 

Best,

Adrian

 

From: [e-mail] <[e-mail]> 
Sent: 29 October 2020 15:26
To: [e-mail]; [e-mail]; [e-mail]
Cc: 'Bin Yeong Yoon' <[e-mail]>; 'Hejia (Jia)' <[e-mail]>; 'Peter Park' <[e-mail]>; 'Italo Busi' <[e-mail]>
Subject: RE: Re: [Teas] Preemption priority in GMPLS signaling for SMP

 

Dear Adiran,

 

Thank you for your email.

 

When a working LSP or a protecting LSP is configured, SMP can also utilize the Setup and Holding priorities in the SESSION_ATTRIBUTE object. Once the working and protecting LSPs are all configured, SMP will use the preemption priority to resolve the competition for shared resources among multiple protecting LSPs. In SMP, the LSP that is preempted by a higher priority should not be torn down. 

 

Yes, 0 is the highest priority value.

 

Thank you again for your interest.

 

Best regards,

 

Jeong-dong

 

 

 

 

 

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

From: "Adrian Farrel" <[e-mail]>

To: "'Jeong-dong Ryoo'" <[e-mail]>; <[e-mail]>; <[e-mail]>;

Cc: "'Bin Yeong Yoon'" <[e-mail]>; "'Hejia (Jia)'" <[e-mail]>; "'Peter Park'" <[e-mail]>; "'Italo Busi'" <[e-mail]>;

Sent: 2020-10-29 (목) 06:00:06 (UTC+09:00)

Subject: Re: [Teas] Preemption priority in GMPLS signaling for SMP

 

Hey Jeong-dong,

 

Can you clarify (for those who have not been following SMP closely) why existing GMPLS signaling pre-emption priorities (session attribute set-up and hold priorities) don’t provide you with what you need?

 

In any case, I would recommend that you use the same order of ranking used for the set-up and hold priorities. That is, 0 is the highest priority. This seems to be what you are suggesting.

 

Best,

Adrian

 

 

 

From: Teas <[e-mail]> On Behalf Of Jeong-dong Ryoo
Sent: 28 October 2020 14:38
To: [e-mail]; [e-mail]
Cc: Bin Yeong Yoon <[e-mail]>; Hejia (Jia) <[e-mail]>; Peter Park <[e-mail]>; Italo Busi <[e-mail]>
Subject: [Teas] Preemption priority in GMPLS signaling for SMP

 

Dear TEAS WG, 
 
This email is to solicit your opinion on how to implement the preemption priority for GMPLS signaling extentions for Shared Mesh Protection, draft-ietf-teas-gmpls-signaling-smp-04. 
 
As described in draft-ietf-teas-gmpls-signaling-smp-04, the preemption priority is to resolve the competition for shared resources among multiple protecting LSPs, when controlled by the Automatic Protection Switching (APS).   
 
The authors of this draft would like to define one octet for the preemption priority values and state that a lower value has a higher priority. And the number of priority levels is up to the network operator. We also want to indicate the preemption priority of a protecting LSP in a new field, by shrinking the size of Reserved field, within the PROTECTION object. 
 
We would appreciate if you can provide your feedbacks on our proposal above. 
 
Best regards, 
 
Jeong-dong (on behalf of co-authors) 




 

_______________________________________________ Teas mailing list [e-mail] https://www.ietf.org/mailman/listinfo/teas