Hi Bruno, Thanks a lot for the review and valuable comments. Sorry I missed this mail during the travel to IETF.
The authors will reply to these comments and produce a new revision accordingly. Best regards, Jie ________________________________________ From: bruno.decra...@orange.com <bruno.decra...@orange.com> Sent: Friday, July 19, 2024 18:02 To: SPRING WG Subject: [spring] draft-ietf-spring-resource-aware-segments Hi authors, WG. As you expressed beliefs that the document is ready for WGLC and asked for WGLC, I’ve been suggested to look again at this draft. Please find below some initial comments. (more are expected in subsequent iterations) 1. Overall document §1 “Introduction” is clear. Thank you. Then, at high level, this standard track document “describes the mechanism” but I find it a little light on the specification side. IOW, in -09 I’m not seeing a specification which can be implemented on different vendors in an interoperable way. I’m not even clear on what’s the global effect would be in a network. I think that the document will need to progress on this before starting a WGLC (not to mention considering asking publication). So I’ll update the wiki to reflect this. Note that essentially, I believe that Robert expressed a similar same point a while back [1] but this has not resulted in change in the draft. ( Intention is to credit Robert for this review, not to put word in his mouth.) > > [Jie] This document defines the resource-aware SID mechanism and the data > > plane behavior > [Robert] Well honestly I am afraid it does not. [1] https://mailarchive.ietf.org/arch/msg/spring/yxX4KDDT2Mc2ZrL1CzLdY9-PRqk/ 1. SRv6 prefix SID Let’s take the example of the SRv6 Prefix SID (“End” Endpoint behavior). 2.a) My understanding is that you are not defining nor modifying the SR Endpoint behavior “End” as defined in RFC 8986. Is that a correct understanding? If so, no change on SR Segment Endpoint Node. If not, please provide the specification of the change to the “End” Endpoint behavior. E.g., https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-policy-resource-gurantee-03#section-2 2.b) Then assuming something is changed, the (specification) change would be on Transit Nodes. Is that a correct understanding? If so, please specify the change that would apply on those forwarding nodes. Such Transit Nodes are doing regular IPv6 forwarding as per RFC 8754. So would that be a change for SRv6/SPRING or for IPv6/6MAN? 2.c) My understand is that the change would apply to the way the LOC prefix is forwarded. Hence nothing specific to each (more specific) SID using this LOC. Is that a correct understanding? If so, the term “resource-aware-segments” seems misleading as there would be nothing specific to a segment (e.g. no resource specific to a segment). Given that the association of resource to the segment is the key part of this document, as per the title and abstract, that’s something that needs to be clarified. If not, and the resource is indeed per segment, I think it would be good for the document to discuss scaling considerations for QoS queues. Especially with VoQ hardware architectures 2.d) What is precisely the resource associated to the Segment, and how is this useful to build a service in the network? As per the Introduction, you seem to be willing to fill a gap with RSVP-TE. But RSVP-TE is setting up Point to Point LSP while SR is building Multi-Point to point Segments. That’s very different. e.g. assuming a network with 1000 routers. Let’s assume that you want to allocate 1% of the network resource for the Prefix Segment to PE1. On ingress PE (e.g. PE2), you would have indeed reserved a higher pool of resource for this Segment (1%, while otherwise the resource for PE1 would statistically be around 1/1000 hence 0.1%) But on the egress P connecting PE1, reserving %1 of the resource for the segment to PE1 would be a severe restriction of resource since essentially the whole interface P-PE1 is dedicated to PE1 hence to the PE1 Prefix Segment. So what would be the desired goal network wide: increase the resource of this segment or constraint the resource of this segment? The problem is essentially the same if you define the resource as a bandwidth (e.g. 100Mb/s). I’ll stop with these very preliminary comments as I’d like to see the answers and an update of the document covering the above points, before digging a bit more on those resource-aware-segments. Thanks, Regards, --Bruno Orange Restricted Orange Restricted ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
