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

[Gyan Mishra <[e-mail]>]

Dear Authors

As Flex Algo specification must be used over SR data plane architecture I
think a section should be added related to flex Algo interaction with SR
policy. It may have been mentioned but I didn’t notice it.

Also in section 9.3 so as I understand we are using the backup path for FRR
path protection.  How the fast 50ms failover restoration can occur is that
its intent based and no PCALC signaling RSVP FRR like make before break
signaling so the path does not have to be pre built as it cannot be pre
built technically as their is no intermediate node state and all state is
“intent based” on the SR source node when the packet per flow hits the
source node.

 I don’t think the backup path can be pre provisioned into the forwarding
plane as their is no state on the intermediate nodes.


I am not sure if below is accurate.

“ The headend MAY compute a-priori and validate such backup candidate

   paths as well as provision them into the forwarding plane as a backup
   for the active path.  A fast re-route mechanism MAY then be used to
   trigger sub 50msec switchover from the active to the backup candidate
   path in the forwarding plane.  Mechanisms like BFD MAY be used for
   fast detection of such failures.”


https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/15/


Kind Regards

Gyan

On Fri, Apr 30, 2021 at 3:15 AM Gyan Mishra <[e-mail]> wrote:

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*