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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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) <
>> [e-mail]> wrote:
>>
>>> Hi Dhruv,
>>>
>>>
>>>
>>> Please check inline below.
>>>
>>>
>>>
>>> *From:* Dhruv Dhody <[e-mail]>
>>> *Sent:* 29 April 2021 15:46
>>> *To:* Ketan Talaulikar (ketant) <[e-mail]>
>>> *Cc:* James Guichard <[e-mail]>; [e-mail];
>>> [e-mail]
>>> *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 <
>>> [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
>>>
>>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*