Hi Bruno, Thanks a lot for your review and comments. Please see replies inline:
From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] Sent: Friday, July 19, 2024 6:02 PM To: SPRING WG <spring@ietf.org> 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/ [Jie] The allocation of resource-aware SIDs and their usage in packet forwarding are described in section 2. For example, for resource-aware Adj-SID, section 2.1 says: "A resource-aware Adj-SID represents a subset of the resources (e.g., bandwidth, buffer and queuing resources) of a given link, thus each resource-aware Adj-SID is associated with a subset of the link's traffic engineering (TE) capabilities and resources (known as TE attributes [RFC2702])." "For one IGP link, multiple resource-aware Adj-SIDs can be allocated, each of which is associated with a subset of the link resources allocated on the link." And "In data packet forwarding, each resource-aware adj-SID identifies both the next-hop and the set of resources used for packet processing on the outgoing interface." To me the above text is clear about how the resource-aware segments are allocated and used. Or do you have specific questions about it? 2) 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 [Jie] The behavior of SRv6 End SID as defined in RFC 8986 is not changed by this document. 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. [Jie] Yes the behavior of the transit nodes are changed. This is described in section 2.1 and 2.2 respectively starting with "In data packet forwarding". We can make it clearer which sentences are about the behavior of the transit 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? [Jie] As described in section 3 of this draft, network nodes need to know (via control plane mechanisms) the SID/Locator is resource-aware and is associated with a resource group, so that packets with the SID as the destination address will be processed by transit nodes using the set of resources associated with the SID. Thus the transit nodes are still doing IPv6 forwarding based on the destination address. It is just that the address (which is a SID) is associated with a set of network resources. In my understanding it is a change to SRv6, while it may not require change to IPv6. 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 [Jie] For SR-MPLS the forwarding behavior are related to the SID, while for SRv6 the forwarding behavior of transit nodes are related to the LOC part of the SID. The term "resource-aware segment" is used to cover both cases. While we can further clarify the difference between SR-MPLS and SRv6 in the semantics. The scaling of per-segment resource allocation is discussed in section 2.1 and 2.2. For resource-aware Adj-SIDs, each SID is associated with a subset of the link resources allocated on the corresponding link (using sub-interfaces or queues). For resource-aware prefix-SIDs, to improve resource efficiency, it is suggested to allocate a common set of resources to a group of resource-aware SIDs. The approach for SRv6 is similar. 2.d) What is precisely the resource associated to the Segment, and how is this useful to build a service in the network? [Jie] As described in the draft, typically resources associated with SR segments can be: bandwidth, buffer, and queueing resources. While it also allows to associate SR SIDs with other type of resources. 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. [Jie] Yes it is important to understand the difference between resource-aware segments and RSVP-TE in terms of resource reservation. With RSVP-TE, the resource reservation is along a point-to-point TE-LSP, and on each hop the amount of bandwidth resource reserved must be the same. With resource-aware segments, the resource allocation is per-segment, this means on each network segment, the amount of resource allocated could be different. The resource reserved for a path is represented by the list of resource-aware segments. And this allows multiple paths to use the same resource-aware segments (hence the same set of resources). Thus resource-aware segment can be used for both P2P, MP2P and MP2MP. 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? [Jie] As mentioned in the reply to question 2.c), the resource allocation for prefix-segment is based on groups. For example, a common set of resources can be allocated to all the Prefix SIDs belonging to a specific topology/algorithm. It is not recommended to allocate dedicated resource network-wide for a specific prefix-SID. Furthermore, please note on different network links, the set of network resources allocated to a group of Prefix-SIDs can be different, there is no restriction on "same bandwidth value or ratio" along a path as in RSVP-TE. Operator can do resource planning for a specific customer or service according to the demand of connectivity and traffic, then allocate network resources on each link accordingly. The problem is essentially the same if you define the resource as a bandwidth (e.g. 100Mb/s). [Jie] The methodology would be the same for bandwidth or other types of resources. 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. [Jie] Thanks again for the review, please let me know if the above replies can help, and further comments are welcome. We will work on an update version with text needed for these comments. Best regards, Jie 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
