Hi Bruno, Thanks a lot for your careful review and detailed comments.
Please see replies inline with [Jie#2]: And Merry Christmas and happy new year! 发件人: bruno.decra...@orange.com <bruno.decra...@orange.com> 发送时间: 2024年12月18日 0:51 收件人: Dongjie (Jimmy) <jie.d...@huawei.com> 抄送: SPRING WG <spring@ietf.org> 主题: RE: draft-ietf-spring-resource-aware-segments Hi Jie, Speaking as an individual contributor. Thanks for your reply, updated draft (-10) and your patience. Please see inline [Bruno] From: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>> Sent: Tuesday, August 20, 2024 11:05 AM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: RE: draft-ietf-spring-resource-aware-segments Hi Bruno, Thanks a lot for your review and comments. Please see replies inline: From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> [mailto:bruno.decra...@orange.com] Sent: Friday, July 19, 2024 6:02 PM To: SPRING WG <spring@ietf.org<mailto: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? [Bruno] Specification of the Local Segments are relatively ok to me. [Jie#2] Great! But I have questions with regards to the specifications of the Global Segments. [Jie#2] Then let’s focus on the global segments. 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. [Bruno] In SRv6 [RC8754], a transit node is a vanilla IPv6 router. In my understanding SRv6 does not change IPv6 forwarding on Transit router. Therefore changing the behavior on transit routers looks like a change to IPv6 rather than SRv6. Also “A transit node is not required to be capable of processing a segment or SRH.” while your proposal seems to mandate that IPv6 transit nodes understand and process resource aware segments. [Jie#2] The transit nodes are not required to process segments or SRH. They would only process the locator part of the segment in the destination IP address field based on longest prefix match. If the transit nodes support SRv6 and resource-aware segments, they would know that the locator of the segment is resource-aware, then they will process the packets using the set of resources associated with the locator. This is similar to the processing of algorithm-specific SRv6 SIDs/locators on transit nodes. If the transit nodes do not support SRv6 or resource-aware segments, they will process the packet as native IPv6 packet. 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. [Bruno] So for SRv6, the forwarding behavior of transit nodes are related to the LOC i.e. an IPv6 prefix. It’s not related to a segment as transit nodes do not process segments. Yes I would welcome clarification in the document. And speaking of clarity I would rather use the term “segment” when it’s a segment and “prefix” when it’s a prefix. [Jie#2] Yes for the transit nodes, the forwarding behavior is related to the LOC part of the segment. We will add clarification text in next version. 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. [Bruno] Local Segment (e.g., Adj-SID) are much clearer than Global Segment (e.g., prefix-SID) so my point if for prefix-SID. For clarity (and interoperability) it would be good to clarify and specify whether the resource is associated to the Segment or to a group of Segments. Because for Global Segments we want global consistency. [Jie#2] I agree the specification for prefix-SID can be further clarified. And in the description the difference between SRv6 and SR-MPLS may also need to be considered. The good news is that this is probably only a terminology / phrasing consideration. E.g., looking at the first sentence of the abstract “This document describes the mechanism to associate network resources to Segment Routing Identifiers (SIDs).” I’m not a native English speaker so eventually y I’m misinterpreting. But I’m reading this as the network resources being associating/allocated/given to the SID. While, as per “ it is suggested to allocate a common set of resources to a group of resource-aware SIDs” the resource does not seem associated to the segment. May be more like segment(s) are associated to network resources. So may be rephrasing as “This document describes the mechanism to associate a set of Segment Routing Identifiers (SIDs) to network resources.”. [Jie#2] Good suggestion, thanks. It looks better and clearer by using “associate a set of SIDs to network resources”. Also the term “associate” is not very clear to me. Could you clarify the two sets and their type of relation ?( e.g., is this a bijection?). Trying to guess, you want to allocate a sub-set of resources to a group of SIDs. So: - the SIDs in this group of SIDs shares theses resources between themselves. - these resources are dedicated to this group of SIDs (no other SID, network traffic may use this resource). [Jie#2] Your guess is correct, especially for the global segments. A group of SIDs share a sub-set of resources, and these resources are dedicated to this group of SIDs. Anyway, I think that a clear description would help. Hopefully right from the abstract. May be simply OLD: This document describes the mechanism to associate network resources to Segment Routing Identifiers (SIDs). NEW: This document describes the mechanism to allocate network resources to a set of Segment Routing Identifiers (SIDs). [Jie#2] The new text looks simple and clear. Thanks for the suggestion. Also the abstract says “The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources.” I find the formulate imprecise and possibly misleading. E.g. a reader could read that the “network resources” are “reserved” for the “SR path”. Which does not seem to be the case. May be NEW: The resource-aware SIDs can therefore be used to allow an SR Policy to use a specific set of network resources [Jie#2] I got your point, and the new text is more accurate, thanks. 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, [Bruno] well it does not seem so. Resource allocation seems per group of segments. [Jie#2] Yes, depending on the type of segment (local or global), it can be per-segment or per-group of segments. this means on each network segment, [Bruno] It’s not crystal clear to me whether “segment” is to be understood as “SR Segment” of “segment/part of a network” [Jie#2] Here the segment means “a part of the network”. the amount of resource allocated could be different. The resource reserved for a path is represented by the list of resource-aware segments. [Bruno] Sorry, totally unclear to me. In particular it’s not clear to me what you mean by “path”, “represented”, “list of ressource-aware segments” (e.g. which list of resource-aware segments, by ‘path” do you mean an SR Policy?) [Jie#2] Sorry, the description “reserved for a path” is not accurate, maybe better to rephrase it as “the set of resource used by an SR Policy is indicated by the list of resource-aware segments which are used to build the segment lists”. 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. [Bruno] OK. Resource is allocated (dedicated?) to a group of segments rather than to a segment. Can this be clarified upfront in the draft? May be providing a definition of a resource aware segment. [Jie#2] OK, will add some clarification text about how the resources are allocated to the segments (local or global). 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. [Bruno] Thanks for the reply. I think we are progressing. Again I’d like to see an updated document with a clear definition and specification of a what is a resource aware global segment, before digging a bit more on the draft. [Jie#2] Thanks for your help in improving the description of the draft. We will prepare an update version with clarifications about the resource-aware global segments. Best regards, Jie Best regards, --Bruno 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. ____________________________________________________________________________________________________________ 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
