Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Dhruv Dhody <[e-mail]>]

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.


> - 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.


>
> - 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.



> - 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

Related question: is there a value in putting aside a few of these for
Experimental Use?


>
> - 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


> 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 <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>