Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

RFC 7473 SAC stands for Selective Advertisement Capability.

Thanks

Gyan

On Wed, Jan 4, 2023 at 2:36 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> +1
>
> Segment Routing has been built for unicast routing for both SR-MPLS and
> SRv6 flavors - “Unicast SR”.
>
> All legacy existing technologies as Jeffrey described MVPN PTAs that exist
> today can all be used with SR and are fully supported with “Unicast SR”.
>
> So there is no rule that legacy MVPN PTA technologies cannot be used with
> SR and are used today widespread  worldwide.
>
> As well MPLS, SR-MPLS and SRv6 can done as dual or multi plane deployments
> multiple  ships in the night where SRv6 network can be used for all Unicast
> traffic snd LDP can still be leveraged for just multicast only traffic.
>
> MVPN legacy stateful PTA’s RFC 6514  all fully supported by SR
>
>       + 0 - No tunnel information present
>       + 1 - RSVP-TE P2MP LSP
>       + 2 - mLDP P2MP LSP
>       + 3 - PIM-SSM Tree
>       + 4 - PIM-SM Tree
>       + 5 - BIDIR-PIM Tree
>       + 6 - Ingress Replication
>       + 7 - mLDP MP2MP LSP
>
>
> BIER is along the lines of stateless
>
> Also BGP Multicast and Multicast Controller are as well stateless and
> along the lines of SR
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller/
>
>
> RFC 7473 Controlling State Advertisements of Non Negotiated LDP
> applications code name (SAC knob)
>
> So with this SAC knob disabled LDP label exchange label mapping message
> for unicast prefixes.
>
> So this eliminates the footprint of LDP in the stack of protocols
> eliminates LDP unicast without having to completely remove LDP and allows
> mLDP extension to continue to be used for multicast applications only.
>
> Replication SID used as a building block for Tree SID is the first SR
> based “IR style” attempt for a P2MP SR based policy for operators that want
> to completely eliminate LDP  from the network.
>
> This is highly valuable and desirable for operators wanting to completely
> eliminate LDP.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy
>
> SR eliminates forwarding state provided by LDP label mapping message LFIB
> by placing all the forwarding stare into the packet by leveraging the SR
> IGP extensions to eliminate the same LDP mapping message label distribution
> which is now being done via SR IGP extension.  As well RSVP-TE elimination
> and putting the steering forwarding state into the packet with SR policy
> BSID binding candidate path for SID list  or label stack to forwarding
> plane pushed onto the packet.
>
> So that is what makes SR “stateless”.
>
> SRs goal is for simplicity and elimination of as many protocols as
> possible using the KISS principle.
>
> However there is still plenty of state with IGP which is something that
> you cannot eliminate as well as BGP state.
>
> However, when we talk about stateless in the context of SR it’s  data
> plane forwarding plane state (LDP and RSVP-TE) elimination that we are
> talking about and not control plane state elimination (IGP / EGP).
>
> Hope this explanation helps!
>
> Kind Regards
>
> Gyan
>
> On Mon, Dec 12, 2022 at 9:08 AM Jeffrey (Zhaohui) Zhang <zzhang=
> 40juniper.net@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>>
>>
>> Replication trees built with replication segments do have per-tree state.
>> However please consider the following:
>>
>>
>>
>> While an SR network does not need per-path state for unicast, it does not
>> mean that multicast must strictly follow the same. Any of the following
>> could be used, depending on an operator’s choice.
>>
>>
>>
>>    1. Ingress Replication or BIER
>>    2. Traditional PIM or mLDP/RSVP P2MP solutions that maintain per-tree
>>    state for efficient replication
>>    3. Replication tree based on replication segments but signaled from
>>    controllers via PCEP/BGP/NETCONF/whatever
>>    4. Other options that are in the discussion in PIM/BIER WGs (e.g.,
>>    BIER-RBS, encoding sub-tree in SRH)
>>
>>
>>
>> #1 is actually independent of SR, yet it sticks to SR principle (of no
>> per-tree state in network) perfectly. However, we also need non-IR/BIER
>> solutions for SR networks.
>>
>>
>>
>> Nobody can reject #2 as a valid option. For the same reason, #3 is also
>> valid and it is what this WGLC is about. #3 allows an SR operator to use
>> controller-based calculation & signaling and move away from PIM/mLDP/RSVP –
>> to me that goes very well with SR even though it still has per-tree state.
>>
>>
>>
>> #3 with MPLS data plane is identical to #2 in the data plane, though
>> we’re introducing this new “replication segment” term to go with the big SR
>> framework. It is also the only non-BIER, non-legacy solution for SR-MPLS
>> data plane (so far).
>>
>>
>>
>> For #3 with SRv6 data plane, while in concept it is similar to #3 with
>> MPLS (the FUNCT bits of an SRv6 SID are the equivalent of P2MP label), we
>> do need the replication segment concept and corresponding endpoint behavior
>> defined for SRv6.
>>
>>
>>
>> In short, this document introduces the replication segment concept and
>> defines the corresponding SRv6 endpoint behavior. It provides the building
>> block for replication trees in SR network that are not necessarily set up
>> via traditional means, and it does not exclude other solutions.
>>
>>
>>
>> Thanks.
>>
>> Jeffrey
>>
>>
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Aijun Wang
>> *Sent:* Saturday, December 10, 2022 8:35 PM
>> *To:* Robert Raszuk <robert@raszuk.net>
>> *Cc:* SPRING WG <spring@ietf.org>; spring-chairs@ietf.org; Huaimo Chen <
>> huaimo.chen@futurewei.com>
>> *Subject:* Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment
>>
>>
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> Hi, Joel and Robert:
>>
>>
>>
>> I think we should clarify what’s kind of state is that we are talking
>> first before making any assertions.
>>
>>
>>
>> What we should avoid in Segments Routing panoramic view is that we
>> shouldn’t introduce the per-flow state within the network.
>>
>>
>>
>> Consider the different multicast services require different multicast
>> trees, you need to store different “Replications Segments” for different
>> multicast services.
>>
>> Isn’t this per-flow state?
>>
>>
>>
>> Based on the same principle, the Binding-SID introduces also some kind of
>> per-flow state in the network——if every different flow needs to take
>> different paths at the advertising node——In such case, you need to keep
>> many or per-flow Binding-SID at the advertising node. It violates certainly
>> the dogmas of segment routing.
>>
>>
>>
>> The other SIDs(or that defined in RFC8986)that you mentioned are the
>> states about the action of the related segment value and they are not
>> Path-related, we can omit them.
>>
>>
>>
>> In summary, the “Replication Segment SID” that introduced in this draft
>> has the similar effects that the MPLS label derived from the various
>> distribution protocol of multicast VPN solutions. Will you also call these
>> MPLS states within the transit nodes as segment routing based?
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> On Dec 11, 2022, at 08:02, Robert Raszuk <robert@raszuk.net> wrote:
>>
>> 
>>
>> Joel,
>>
>>
>>
>> Yes IMO your understanding is correct.
>>
>>
>>
>> That does also mean that anyone who is making assertions that the subject
>> document is introducing per flow "state" is just wrong or simply does not
>> understand SR dogmas.
>>
>>
>>
>> Cheers,
>> Robert.
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Dec 11, 2022 at 12:42 AM Joel Halpern <jmh@joelhalpern.com>
>> wrote:
>>
>> Speaking personally, my understanding of the "stateless" aspect of SR
>> does not match what this email seems to describe.
>>
>> SR is path stateless.  There is no state related to specific paths across
>> the network.  Any SID may be used, if it has relevant meaning, in any path.
>>
>> Advertising routers have internal state about what they mean when the
>> advertise SIDs.
>>
>> Transit rotuers have state about where to forward packets based on the
>> current SID in the packet.
>>
>> Binding SIDs have stored state about what stack of labels replace the
>> binding SID at the advertising router.
>>
>> All these forms of state are considered by the community, as far as I can
>> tell, as acceptable and reasonable forms of state with SR.
>>
>>
>>
>> Personally, it seems to me that replication SIDs have much the same kinds
>> of state, and therefore fit well in the SR architecture.
>>
>> Yours,
>>
>> Joel
>>
>>
>>
>> On 12/9/2022 11:53 AM, Huaimo Chen wrote:
>>
>> Hi Everyone,
>>
>>
>>
>>     It seems that the core value of segment routing is stateless (in the
>> core of a network). The document defines a new type of segment for
>> Segment Routing [RFC8402], called Replication segment. Using Replication
>> segment is not stateless. This is not consistent with the core value of
>> segment routing. I oppose the progress of the document.
>>
>>
>>
>> Best Regards,
>>
>> Huaimo
>> ------------------------------
>>
>> *From:* spring <spring-bounces@ietf.org> <spring-bounces@ietf.org> on
>> behalf of James Guichard <james.n.guichard@futurewei.com>
>> <james.n.guichard@futurewei.com>
>> *Sent:* Monday, November 28, 2022 10:10 AM
>> *To:* SPRING WG <spring@ietf.org> <spring@ietf.org>
>> *Cc:* spring-chairs@ietf.org <spring-chairs@ietf.org>
>> <spring-chairs@ietf.org>
>> *Subject:* [spring] WGLC for draft-ietf-spring-sr-replication-segment
>>
>>
>>
>> Dear WG:
>>
>>
>>
>> This email starts a 2-week Working Group Last Call for
>> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
>> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-spring-sr-replication-segment*2F&data=05*7C01*7Chuaimo.chen*40futurewei.com*7C385b4881095c41b2c27008dad152b258*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C638052450396258660*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*7C*7C*7C&sdata=Xc85avPl8dZMqGuCSXAA6f89OTvRfQfQ6MGa9NCQnBE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Aap0ylLmZYJ1m1MjpemXu4Fz7a4wq8hOk2RxE7cl_MTy9LmWoS0sxaf9JZve052OYvuoksWxsH1wBIomHPupKiGX$>
>>
>>
>>
>> Please read the updated document if you haven’t already and send your
>> comments to the SPRING WG list no later than December 12th 2022.
>>
>>
>>
>> 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 contributor please respond to indicate
>> whether you know of any undisclosed IPR related to this document.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Jim, Joel & Bruno
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> spring mailing list
>>
>> spring@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/spring <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Aap0ylLmZYJ1m1MjpemXu4Fz7a4wq8hOk2RxE7cl_MTy9LmWoS0sxaf9JZve052OYvuoksWxsH1wBIomHJ7SA_l8$>
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Aap0ylLmZYJ1m1MjpemXu4Fz7a4wq8hOk2RxE7cl_MTy9LmWoS0sxaf9JZve052OYvuoksWxsH1wBIomHJ7SA_l8$>
>>
>> _______________________________________________
>> 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.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*