Dear Authors In the Abstract and Introduction you could say that the intermediate node control plane state maintenance is eliminated as now the same functionality of a label binding is now provided with IGP SR extension per SR architecture.
Kind Regards Gyan On Fri, Apr 30, 2021 at 3:06 AM Gyan Mishra <hayabusa...@gmail.com> wrote: > Dear WG Authors > > This draft is very well written and I support publication. > > Few minor comments > > Abstract and Introduction > > I would reword “ Intermediate per-flow states are eliminated thanks to > source routing.” > > I would reword saying the header of a packet is steered into an SR policy > as it’s the entire packet including overlay payload and not just the > header. Also saying that intermediate per flow state is eliminated is not > accurate even though RFC 8402 does state so it’s not accurate. So the > concept of “per flow” implies per packet used in EVPN MHD/MHN or with IPv6 > flow label stateless uniform load balancing. Flow based implies flow based > load balancing of the entire flow which is subject to polarization uneven > load balancing. In MPLS framework which SR-MPLS reused the MPLS data plane > even with entropy label the ECMP control and data plane extra per path > label state is eliminated but the flows are still flow based load balanced > and not per packet as is implied with “per flow” statement. In the MPLS > framework all interesting packets flow along LSP path to egress PE FEC > destination for all VPNs unless per VPN to TE next hop rewrite feature is > utilized and then each VPN can map to a different RSVP tunnel. Long story > short - reasons above as to the rewrite of Abstract as well as Introduction > sentence where “per flow” is mentioned. > > What is eliminated with SR is LDP and RSVP TE control plane signaling > state not flow state. In both SR and MPLS the flow state exist but now > with SR the per flow steering has much more granularity. This does bring > up another very critical point. I can understand SRv6 as it used the IPv6 > data plane and with RFC 6437 flow label you get per flow per packet uniform > distribution load balancing however with SR-MPLSv4 you would still be > subject to flow based load balancing hash meaning all packets that are part > of the same flow would be steered along the same ECMP prefix sid path > instantiated as oppose to SRv6 which can take advantage of flow label > uniform load balancing. At the bottom of the draft where you get into > coloring of flows per destination coloring would work but section 8.6 per > flow steering would not work as you are still subject to IPv4 flow based > load balancing polarization of packets. On the other hand if SR-MPLSv6 was > used that would be MPLS over v6 core and you now have flow label providing > entropy for load balancing now the per flow load balancing per flow > coloring would now work. > > In the draft you mentioned that all of the draft uses MPLS data plane for > the examples but given the issue I am bringing up I think maybe at least > mention SRv6 if you don’t want to mention SR-MPLSv6 which would be not as > common. As their can be more nuances between MPLS data plane and IPv6 data > plane I think having both examples and taking into account both throughout > the draft for consistency and also to ensure nothing technical get > overlooked in the specification. > > NEW Abstract > > Segment Routing (SR) allows a headend node to steer a packet flow > along any path. Intermediate node control plane signaling is eliminated > by source routing. The headend node can now steer any discrete flow into > an > > instantiated SR Policy path. > > The per flow packets are now steered into an SR Policy made up of an > ordered list of transport topological segments . This > document details the forwarding plane concepts of SR Policy and per flow > steering into an SR > Policy explicit path. > > > Section 2 minor typo > > An instruction is a segment so I think you meant binding of the > topological SID instructions advertised in the IGP extension is what is > bound to the prefix FEC binding in the case of MPLS > data plane and SRv6 a binding. > > OLD > > The Segment Routing architecture. > > [RFC8402 <https://tools.ietf.org/html/rfc8402>] specifies that any > instruction can be bound to a segment. Thus, an SR Policy can be > built using any type of Segment Identifier (SID) including those > associated with topological or service instructions. > > > NEW > > > The Segment Routing architecture [RFC8402 > <https://tools.ietf.org/html/rfc8402>] specifies that any > Prefix can be bound to a segment. Thus, an SR Policy can be > built using any type of Segment Identifier (SID) including those > associated with topological or service instructions. > > > Kind Regards > > Gyan > > On Fri, Apr 30, 2021 at 2:13 AM Dhruv Dhody <dhruv.i...@gmail.com> wrote: > >> Hi Ketan >> >> Thanks for handling the comments. Just a final comment on the >> security/manageability considerations that explains my reasoning. I would >> let you/shepherd take a call! >> >> This draft describes the SR Policy with a common informational model >> which has proven to be quite useful. I would like to see this approach >> extended to also capture the security and manageability aspects in a >> protocol-agnostic way. The configuration of SR policy, the verification >> rules, SR-DB handling, various policies that control active path selection, >> are all common and should be listed in this I-D. You could also give clear >> requirements for the protocols to build on. There have been cases where the >> protocols have differed leading to issues. Having a section in this I-D >> that lays out clearly for protocols would be useful. As the work is >> distributed across WG, IMHO having a SPRING WG consensus on such a text >> would be nice. >> >> Just my 2 paisa :) >> Stay Safe! >> >> Thanks! >> Dhruv >> >> >> On Thu, Apr 29, 2021 at 7:40 PM Ketan Talaulikar (ketant) < >> ket...@cisco.com> wrote: >> >>> Hi Dhruv, >>> >>> >>> >>> Please check inline below. >>> >>> >>> >>> *From:* Dhruv Dhody <dhruv.i...@gmail.com> >>> *Sent:* 29 April 2021 15:46 >>> *To:* Ketan Talaulikar (ketant) <ket...@cisco.com> >>> *Cc:* James Guichard <james.n.guich...@futurewei.com>; spring@ietf.org; >>> spring-cha...@ietf.org >>> *Subject:* Re: [spring] WGLC for >>> draft-ietf-spring-segment-routing-policy >>> >>> >>> >>> Hi Ketan, >>> >>> >>> >>> Thanks for the discussion. Sniping to - >>> >>> >>> >>> >>> >>> If a node is identified by multiple addresses, from the point of view of >>> the SR policy they would be considered as different nodes, correct? >>> >>> *[KT] This relates to the computation of SR Policy which is outside the >>> scope of this document. There was some text around computation aspects in >>> an earlier version of the draft that has been moved into >>> draft-filsfils-spring-sr-policy-considerations around the WG adoption time. >>> To answer your question, the endpoint address can be mapped to a node which >>> becomes the tail-end and then path is computed to that node. In that case, >>> multiple addresses may all map to a single node. This would be an >>> implementation aspect.* >>> >>> >>> >>> [Dhruv]: I was thinking from the SR policy identification point of view, >>> i.e. <H1-IP1, color, endpoint> and <H1-IP2, color, endpoint> will be >>> considered as different SR policies even though H1-IP1 and H1-IP2 belong to >>> the same headend H1. >>> >>> *[KT] Yes, they would be different SR Policies.* >>> >>> >>> >>> >>> - Section 2.3, What are the 8-bit values for the Protocol-Origin, is >>> there an existing registry that is used here? Is it - >>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-14#section-9.4 >>> , should it be listed in this document perhaps? >>> >>> *[KT] These are not code points but suggested default values for the >>> Priority assigned to each protocol. An implementation may use a completely >>> different scheme and/or make theme configurable. I see that >>> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2 >>> <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-04#section-5.2.2> >>> does not clearly indicate this and perhaps the authors should clarify that >>> the Protocol Origin in that PCEP TLV is used to tweak/signal the Priority >>> value to be used for that particular CP in the tiebreaker.* >>> >>> >>> >>> >>> [Dhruv]: I am referring to this text - >>> >>> Protocol-Origin of a candidate path is an 8-bit value which >>> identifies the component or protocol that originates or signals the >>> candidate path. >>> >>> Which says that an "8-bit value" identifies the protocol as PCEP, BGP, >>> etc. What you are describing is the priority associated with the >>> protocol. I feel the term "Protocol-Origin" and "Protocol-Origin >>> Priority" is used interchangeably, leading to this misunderstanding. >>> >>> To confirm, in the example - Candidate-path CP1 <protocol-origin = 20, >>> originator = 100:1.1.1.1, discriminator = 1>. The value 20 identify BGP or >>> the Priority value associated with BGP? I am assuming it is the >>> priority! >>> >>> In which case some cleanup of text is needed to make things clear. >>> >>> *[KT] I see your point. The use of “priority” and that too >>> inconsistently might be the cause for the confusion. Will clean-up the text >>> around this.* >>> >>> >>> >>> >>> - Section 10, It might be a good idea to acknowledge security >>> considerations from the SR policy architecture point of view: how various >>> SR policy parameters and attributes could be exploited to make a headend to >>> forward the traffic incorrectly. It is better to add details that clearly >>> show that the authors/WG have given it a thought and analyzed the >>> implications. >>> >>> *[KT] As a reminder the SR Policy has been introduced in RFC8402 which >>> covers these aspects of incorrect routing and other challenges associated >>> with source routing. This document is only providing the details of the >>> implementation construct/framework for the SR Policy.* >>> >>> >>> >>> >>> >>> [Dhruv]: In my reading, RFC 8402 security considerations are focused on >>> the data plane and not much on the interaction between the controller and >>> SR nodes where the SR policy architecture comes in. >>> >>> *[KT] This document does not cover the actual protocols used for >>> interactions between controller and routers – that is covered via PCEP and >>> BGP documents.* >>> >>> >>> >>> >>> >>> - Section 11, What is the range of the value for Segment Types? A-Z >>> only? It would be good to be clear about this. With A-K already allocated, >>> worth thinking if this is too restrictive and not future-proof. Perhaps we >>> could think of the value as a string that is currently populated with a >>> single alphabetic character. >>> >>> *[KT] String can become freeform. How about A-Z, then AA-AZ … ZA-ZZ – >>> that should be a large enough space?* >>> >>> >>> >>> [Dhruv]: That works. Maybe you could add this to the table to clearly >>> indicate the range: >>> L-Z: Unassigned >>> AA-ZZ: Unassigned >>> >>> *[KT] I’ll try to describe this in the text since the AA-ZZ might not be >>> very clear.* >>> >>> >>> >>> Related question: is there a value in putting aside a few of these for >>> Experimental Use? >>> >>> *[KT] I don’t think so because these are not signaled in any protocol.* >>> >>> >>> >>> >>> - Since the I-D talks about policy configuration, explicit candidate >>> paths, verification, SR-DB, etc. I don't want to add work for the authors >>> but I do feel in this case a dedicated manageability consideration section >>> would be useful :) >>> >>> *[KT] Good catch. I will add it. It is not much work really since we >>> need to point to RFC8402 which introduced the SR Policy and an informative >>> reference to draft-ietf-spring-sr-policy-yang that the WG is already >>> working on.* >>> >>> >>> >>> >>> >>> [Dhruv]: That helps, but also think in lines of documenting some key >>> considerations as per >>> https://datatracker.ietf.org/doc/html/rfc5706#section-2 >>> >>> *[KT] This is not really a new protocol per-se and I am not sure if this >>> is necessary. However, if there are any text proposals, we can discuss >>> within the WG.* >>> >>> >>> >>> *Thanks,* >>> >>> *Ketan* >>> >>> >>> >>> Hope the authors and WG find these suggestions useful. >>> >>> *[KT] Yes, definitely.* >>> >>> >>> >>> Thanks! >>> >>> Dhruv >>> >>> >>> >>> >>> >>> >>> >>> *Thanks,* >>> >>> *Ketan* >>> >>> Thanks! >>> Dhruv >>> >>> On Fri, Apr 16, 2021 at 12:27 AM James Guichard < >>> james.n.guich...@futurewei.com> wrote: >>> >>> Dear WG: >>> >>> >>> >>> This email starts a 2 week Working Group Last Call for >>> draft-ietf-spring-segment-routing-policy [1]. >>> >>> >>> >>> Please read this document if you haven’t read the most recent version >>> and send your comments to the SPRING WG list no later than April 29th >>> 2021. >>> >>> >>> >>> If you are raising a point which you expect will be specifically debated >>> on the mailing list, consider using a specific email/thread for this point. >>> >>> >>> >>> Lastly, if you are an author or contributors for this document please >>> response to the IPR call in the previous email thread. >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Jim, Joel & Bruno >>> >>> >>> >>> [1] >>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
