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

Another important concept with multicast is hard state versus soft state
which is applicable to be discussed here in the context of SR having state
or not related to SR nature of being stateless forwarding state technology.

Multicast has traditionally used soft state PIM based tree building
protocols for ASM and SSM models over stateful forwarding qprotocols such
as mLDP and RSVP-TE.

BGP Multicast and BGP controller multicast drafts below  leverage the SP
MVPN style always on hard state that gets built for X-PMSI UI/MI via Leaf
AD   RT-4 MVPN procedures.

BGP Multicast
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-00

BGP Controller Multicast
https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller/

With Replication SID you have a very similar MVPN  IR PTA style replication
state on parent nodes which is hard state and not soft state analogous to
BGP multicast using SP MVPN procedures hard state described above.

Thanks

Gyan

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

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

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