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) <[email protected]> wrote: > Hi Dhruv, > > > > Please check inline below. > > > > *From:* Dhruv Dhody <[email protected]> > *Sent:* 29 April 2021 15:46 > *To:* Ketan Talaulikar (ketant) <[email protected]> > *Cc:* James Guichard <[email protected]>; [email protected]; > [email protected] > *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 < > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
