Re: [Lsr] [spring] Intended status ofdraft-ietf-spring-resource-aware-segments

[Liyan Gong <[e-mail]>]

Hi All，


Thank you for all your sharing.  I have read the discussion carefully and I agree the following opinions------"the resource-aware SIDs would be associated with a set of network resource", and "the control plane mechanisms is necessary to advertise the resource-aware SIDs and their associated resource attributes". 


But, it is indeed difficult and unreasonable to advertise huge amount of informations in current IGP protocol since it will introduce tremendous system burden.


To resolve this problem, we proposed a solution [1] to advertise SIDs and attributes as a resource group in IGP protocol.


We are still working on it and hope to get feedbacks and comments from LSR and SPRING WG. Thanks a lot. 





[1]: https://www.ietf.org/archive/id/draft-cheng-lsr-advertise-nrp-group-extensions-01.txt





----邮件原文----发件人：Gyan Mishra  <[e-mail]>收件人："Dongjie (Jimmy)" <[e-mail]>抄　送: Alexander Vainshtein  <[e-mail]>,"[e-mail]" <[e-mail]>,"[e-mail]" <[e-mail]>发送时间：2024-01-26 08:49:36主题：Re: [spring] Intended status ofdraft-ietf-spring-resource-aware-segmentsHi Jie 
Responses in-line Gyan>




Gyan Mishra


Network Solutions Architect 


Email [e-mail]


M 301 502-1347














On Wed, Jan 24, 2024 at 2:57 AM Dongjie (Jimmy) <[e-mail]> wrote:


Hi Gyan, 


 


Thanks for sharing your thoughts on this document. 


 Gyan> Welcome 


I agree with you that in this document the semantics of the existing SR SIDs (the topological SIDs in your text) are extended to “topology/function  + resource”, thus the forwarding behavior of the resource-aware SIDs will be a little bit different from the normal SID. While the encoding of the SR SIDs are still unchanged. This may be a subtle change/update to SR, while it would be good if this could be  reflected by the document type. 


 Gyan> So with that subtle change/update to SR control plane in my email was referring to maybe an LSR draft for the resource sid extension TLV encoding of the resource information.








As for the control plane mechanisms to advertise the resource-aware SIDs and their associated resource attributes, there can be either solutions  which reuse existing protocol mechanisms, or protocol extensions may be introduced for the enhancements of capability for some scenarios. That has been discussed in TEAS and the corresponding control protocol WGs, and hopefully that discussion will continue  there. 


 Gyan> Understood.  So one way would be an IGP extension however due to the subtle change their could be other methods to accomplish how to encode the resource sid extension information.


Hope this helps to align our understanding on this document. 


Gyan> Yes Thank you  


Best regards,


Jie


 




From: Gyan Mishra [mailto:[e-mail]] Sent: Tuesday, January 23, 2024 2:02 PM To: Dongjie (Jimmy) <jie.dong=[e-mail]> Cc: Alexander Vainshtein <[e-mail]> [e-mail] [e-mail] Subject: Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments




 


 


Hi Jie



 


I understand the draft proposes an extension to existing topological SIDs to carry the resource attributes.



 


However since this draft proposes a new resource attributes extension encoding to existing topological SIDs I agree this should be standards track.



 


Since the topological segments are advertised by IGP OSPF or ISIS, I am guessing you would have a standards track draft in LSR that encodes the resource segments and could update the existing SR-MPLS and SRv6, OSPF and  ISIS RFCs / drafts.



 


You could possibly mention the proposed encoding scheme and fields and that detail would be integrated into the IGP draft.



 


Another option would be to introduce new resource aware SIDs that is NRP centric  that would be applicable to both  SR-MPLS and SRv6 but would be independent of topological or service SID so not at that layer.  The resource  SID would be associated with the BSID that binds the single or multiple candidate path to the forwarding plane and instantiates the path.  So for SR-MPLS it would be the entire label stack pushed onto the packet when the BSID is popped.  For SRv6 it would  be SRH segment list associated with the candidate paths.



 


In this option you would have a standards track draft in LSR that encodes the resource segments and could update the existing SR-MPLS and SRv6, OSPF and  ISIS RFCs / drafts.



 


The contents of the resource SID would now apply to the NRP and would be as you described, buffers, queues, bandwidth, SLO and SLE  parameters such as latency  and jitter for NRP network slice.



 


Kind Regards 



 




Gyan Mishra


Network Solutions Architect 


Email [e-mail]


M 301 502-1347



 












 


 


On Mon, Jan 22, 2024 at 3:39 AM Dongjie (Jimmy) <jie.dong=[e-mail]> wrote:



Hi Sasha, 


 


Thanks for the review and comment on this document. 


 


Although this draft does not introduce new SR segment type/SRv6 behavior, there is change  in the semantics and forwarding behavior of the resource-aware segments, as each resource-aware SIDs identifies a subset of the network resources used for packet processing. 


 


Thus the authors consider this document belong to standard track. That said, the usage  of IETF keywords in current version needs to be revisited and adjusted if needed. 


 


Of course we would like to hear the opinions from the WG participants, and follow the  decision of the WG. 


 


Best regards,


Jie




 




From: spring [mailto:[e-mail]] On Behalf Of Alexander Vainshtein Sent: Sunday, January 21, 2024 2:16 PM To: [e-mail] Cc: [e-mail] Subject: [spring] Intended status of draft-ietf-spring-resource-aware-segments




 


Hello,


I have read the draft,  and I do not have any technical comments on it.


At the same time, I wonder why its intended status appears as “Standard Track”:


1.  The draft does not define any new mechanisms in the data plane or control plane


2.  Usage of the IETF keywords denoting requirement levels looks too vague/generic to me, e.g.


a.  The details of the underlay network MUST NOT be exposed to third parties, to prevent attacks aimed at exploiting shared network resources


b.  If there are related link advertisements, then consistency MUST be assured across that set of advertisements













 


IMHO and FWIW the draft describes how resource-aware forwarding can be achieved using various already-defined SR mechanisms.


 


Have the authors and/or the WG considered changing the intended status of the draft to “Informational”?


 


Regards,


Sasha


 


 

Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole  use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies,  including any attachments. 





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