Re: [spring] SR-MPLS over IPv6？

["Joel M. Halpern" <[e-mail]>]

SR is Stateless in the sense of not having per-path state.  It is not 
stateless in a general sense, since otherwise MPLS-SR would not be SR 
(it needs label state).  So I think we are reading 8402 differently.

We can let the marketing folks fight it out in the marketplace.

Yours,
Joel

On 9/25/2019 3:41 PM, Bernier, Daniel wrote:
> Hi Ron,
> 
> Similarly I would refrain from using the SR acronym since a key 
> characteristic of the SR architecture as per RFC8402 is statelessness.
> 
> As per current SRv6+ documents, state is required for an intermediate 
> node to add the relevant next PSSIs in DOH. This is whether they are 
> domain-wide defined or with local significance (i.e. prepending short-SID).
> 
> Cheers,
> 
> Dan B
> 
> On 2019-09-25, 8:43 AM, "Jeff Tantsura" <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> Agree with Stuart.
> 
> SRinUDP is a well defined solution, let’s not mix things.
> 
> Cheers,
> 
> Jeff
> 
> On Sep 25, 2019, 2:39 PM +0200, Stewart Bryant 
> <[e-mail]>, wrote:
> 
>     I agree.
> 
>     Inclusion of the term MPLS would cause confusion with
>     draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The
>     design decribed in draft-ietf-mpls-sr-over-ip works over both IPv4
>     and IPv6. Also course, as Ron states, such a name is not a true
>     refelction of the design.
> 
>     - Stewart
> 
>     On 24/09/2019 05:01, Ron Bonica wrote:
> 
>         Cheng,
> 
>         I have no problem with changing the name. SR-MPLS over IPv6 may
>         not be appropriate, because MPLS is not part of the solution.
> 
>         Something like SR-extensible-6 or SR-compressed-6 might work.
> 
>                                                                         Ron
> 
>         Juniper Business Use Only
> 
>         *From:* Chengli (Cheng Li) <[e-mail]>
>         <mailto:[e-mail]>
>         *Sent:* Monday, September 23, 2019 10:14 PM
>         *To:* Ron Bonica <[e-mail]>
>         <mailto:[e-mail]>; Jeff Tantsura
>         <[e-mail]> <mailto:[e-mail]>
>         *Cc:* SING Team <[e-mail]>
>         <mailto:[e-mail]>; EXT -
>         [e-mail] <mailto:[e-mail]>
>         <[e-mail]> <mailto:[e-mail]>; SPRING
>         WG List <[e-mail]> <mailto:[e-mail]>
>         *Subject:* RE: [spring] SR-MPLS over IPv6？
> 
>         Oh, I misunderstood the BSID in CRH in last email, sorry for that.
> 
>         Yes, the SID is not an IPv6 address in CRH, but a 16/32 bit
>         value like MPLS label.
> 
>         Therefore, IMHO, it may not comply with RFC8402:
>         https://tools.ietf.org/html/rfc8402#section-3.1.3
>         <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-3.1.3__;Iw!8WoA6RjC81c!WoPYW9IpnDYjcdhli0b80_-KyrOIBYFAZfip_NxPLB1-Bt7oHjt8uGU68K49j2yk$>
> 
>         If possible, I suggest to change the name of SRv6+, since it is
>         not SRv6 based. Something like SR-MPLS over IPv6 maybe better?
> 
>         Thanks,
> 
>         Cheng
> 
>         *From:* Ron Bonica [mailto:[e-mail]]
>         *Sent:* Monday, September 23, 2019 10:45 PM
>         *To:* Chengli (Cheng Li) <[e-mail]
>         <mailto:[e-mail]>>; Jeff Tantsura
>         <[e-mail] <mailto:[e-mail]>>
>         *Cc:* SING Team <[e-mail]
>         <mailto:[e-mail]>>; EXT -
>         [e-mail] <mailto:[e-mail]>
>         <[e-mail] <mailto:[e-mail]>>; SPRING
>         WG List <[e-mail] <mailto:[e-mail]>>
>         *Subject:* RE: [spring] A note on CRH and on going testing
> 
>         Cheng,
> 
>         In SRv6+, it would be very difficult to pollute the architecture
>         because:
> 
>         -A SID is either 16-or 32-bits long
> 
>         -An IPv6 address is 128-bits long
> 
>         -Therefore, it is impossible to copy a SID to an IPv6 address or
>         an IPv6 address to a SID
> 
>         The binding SID will be a 16-or 32-bit topological instruction,
>         found in the CRH. Like all topological instructions, it will
>         identify an SFIB entry.
> 
>         There will be a new SFIB entry type that will contain the
>         following information:
> 
>         -An IPv6 Destination Address (to be used in the outer IPv6 header)
> 
>         -A list of SIDs (to be used in the CRH
> 
>                                                                 
>                   Ron
> 
>         Juniper Business Use Only
> 
>         *From:* Chengli (Cheng Li) <[e-mail]
>         <mailto:[e-mail]>>
>         *Sent:* Sunday, September 22, 2019 12:01 AM
>         *To:* Ron Bonica <[e-mail]
>         <mailto:[e-mail]>>; Jeff Tantsura
>         <[e-mail] <mailto:[e-mail]>>
>         *Cc:* SING Team <[e-mail]
>         <mailto:[e-mail]>>; EXT -
>         [e-mail] <mailto:[e-mail]>
>         <[e-mail] <mailto:[e-mail]>>; SPRING
>         WG List <[e-mail] <mailto:[e-mail]>>
>         *Subject:* RE: [spring] A note on CRH and on going testing
> 
>         Hi Ron,
> 
>         Good to hear that. Looking forward to seeing it in the next
>         revision.
> 
>         But I am curious that is a bind SID in CRH an interface IPv6
>         address only without any other semantics? Just like the other
>         SIDs you mentioned in CRH.
> 
>         If not, this binding SID should not be introduced in to CRH
>         since it pollutes the architecture.
> 
>         If yes, what’s the standard for an Interface IPv6 address?
> 
>         Thanks for confirming that BSID is needed in CRH. I totally
>         agree with you.
> 
>         Best regards,
>         Cheng
> 
>         ------------------------------------------------------------------------
> 
>         李呈Cheng Li
>         Email: [e-mail] <mailto:[e-mail]>
> 
>         *From:* Ron Bonica<[e-mail] <mailto:[e-mail]>>
> 
>         *To:* Jeff Tantsura<[e-mail]
>         <mailto:[e-mail]>>;Chengli (Cheng
>         Li)<[e-mail] <mailto:[e-mail]>>
> 
>         *Cc:* SING Team<[e-mail]
>         <mailto:[e-mail]>>;EXT -
>         daniel.bernier<[e-mail]
>         <mailto:[e-mail]>>;SPRING WG List<[e-mail]
>         <mailto:[e-mail]>>
> 
>         *Subject:* RE: [spring] A note on CRH and on going testing
> 
>         *Time:* 2019-09-22 04:37:17
> 
>         Jeff,
> 
>         After an off-line conversation with the SRv6+ implementors, we
>         decided that it would be trivial to add a binding SID to SRv6+.
>         So, we will do that in the next version of the draft.
> 
>         In keeping with RFC 8200, it will prepend only. Since the CRH is
>         short, insertion is not needed.
> 
>                                                                                                                 Ron
> 
>         Juniper Business Use Only
> 
>         *From:* Jeff Tantsura <[e-mail]
>         <mailto:[e-mail]>>
>         *Sent:* Saturday, September 21, 2019 4:32 PM
>         *To:* Chengli (Cheng Li) <[e-mail]
>         <mailto:[e-mail]>>; Ron Bonica <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* SING Team <[e-mail]
>         <mailto:[e-mail]>>; EXT -
>         [e-mail] <mailto:[e-mail]>
>         <[e-mail] <mailto:[e-mail]>>; SPRING
>         WG List <[e-mail] <mailto:[e-mail]>>
>         *Subject:* RE: [spring] A note on CRH and on going testing
> 
>         Hi Ron,
> 
>         Thanks for your comments, exactly, BSID MPLS label = CRH value :)
> 
>         Cheers,
> 
>         Jeff
> 
>         On Sep 20, 2019, 11:09 AM -0700, Ron Bonica <[e-mail]
>         <mailto:[e-mail]>>, wrote:
> 
>             Hi Jeff,
> 
>             It would be easy enough to add a binding SID to SRv6+. Given
>             customer demand, I would not be averse to adding one.
> 
>             However, there is another way to get exactly the same
>             behavior on the forwarding plane without adding a new SID type.
> 
>             Assume that on Node N, we have the following SFIB entry:
> 
>             ·SID: 123
> 
>             ·IPv6 address: 2001:db8::1
> 
>             ·SID type: prefix SID
> 
>             Now assume that was also have the following route on Node N:
> 
>             2001:db8::1 -> SRv6+ tunnel with specified destination
>             address and CRH
> 
>             This gives you the same forwarding behavior as a binding SID.
> 
>                                                                         Ron
> 
>             Juniper Business Use Only
> 
>             *From:* spring <[e-mail]
>             <mailto:[e-mail]>> *On Behalf Of* Jeff Tantsura
>             *Sent:* Thursday, September 19, 2019 10:53 PM
>             *To:* Chengli (Cheng Li) <[e-mail]
>             <mailto:[e-mail]>>
>             *Cc:* SING Team <[e-mail]
>             <mailto:[e-mail]>>; EXT -
>             [e-mail] <mailto:[e-mail]>
>             <[e-mail] <mailto:[e-mail]>>;
>             SPRING WG List <[e-mail] <mailto:[e-mail]>>
>             *Subject:* Re: [spring] A note on CRH and on going testing
> 
>             There’s number of solutions on the market that extensively
>             use BSID for multi-domain as well as multi-layer signaling.
> 
>             Regards,
> 
>             Jeff
> 
> 
>             On Sep 19, 2019, at 19:49, Chengli (Cheng Li)
>             <[e-mail] <mailto:[e-mail]>> wrote:
> 
>                 +1.
> 
>                 As I mentioned before, Binding SID is not only for
>                 shortening SID list.
> 
>                 We should see the important part of binding SID in
>                 inter-domain routing,  since it hides the details of
>                 intra-domain. Security and Privacy are always important.
> 
>                 Since the EH insertion related text will be removed from
>                 SRv6 NP draft, I don’t think anyone will still say we
>                 don’t need binding SID.
> 
>                 Let’s be honest, Encap mode Binding SID is very useful
>                 in inter-domain routing. It is not secure to share
>                 internal info outside a trusted network domain.
> 
>                 Cheng
> 
>                 *From:* spring [mailto:[e-mail]] *On
>                 Behalf Of* Bernier, Daniel
>                 *Sent:* Thursday, September 19, 2019 11:36 PM
>                 *To:* SING Team <[e-mail]
>                 <mailto:[e-mail]>>
>                 *Cc:* 'SPRING WG List' <[e-mail]
>                 <mailto:[e-mail]>>
>                 *Subject:* Re: [spring] A note on CRH and on going testing
> 
>                 +1
> 
>                 This is what we did on our multi-cloud trials.
> 
>                 Encap with Binding SID to avoid inter-domain mapping + I
>                 don’t need to have some sort of inter-domain alignment
>                 of PSSIs
> 
>                 Dan
> 
>                 On 2019-09-19, 11:18 AM, "spring on behalf of SING Team"
>                 <[e-mail]
>                 <mailto:[e-mail]> on behalf of
>                 [e-mail]
>                 <mailto:[e-mail]>> wrote:
> 
>                 Hi Andrew,
> 
>                 Good to hear that reality experiment :)
> 
>                 But is it secure to share internal SID-IP mappings
>                 outside a trusted network domain?
> 
>                 Or is there an analogue like Binding SID of SRv6, in SRv6+?
> 
>                 Btw, PSSI and PPSI can not do that now, right?
> 
>                 Best regards,
>                 Moonlight Thoughts
> 
> 
>                 (mail failure, try to cc to spring again.)
> 
>                 On 09/19/2019 17:49, Andrew Alston
>                 <mailto:[e-mail]> wrote:
>                 Hi Guys,
> 
>                 I thought this may be of interest in light of
>                 discussions around deployments and running code -
>                 because one of the things we've been testing is
>                 inter-domain traffic steering with CRH on both our DPDK
>                 implementation and another implementation.
> 
>                 So - the setup we used last night:
> 
>                 6 systems in a lab - one of which linked to the open
>                 internet.  Call these S1 -> S6
>                 3 systems in a lab on the other side of the world - no
>                 peering between the networks in question.  Call these R1
>                 -> R3
> 
>                 We applied a SID list on S1, that steered S1 -> S2 -> S3
>                 -> S6 -> R1 -> R3, with the relevant mappings from the
>                 CRH SID's to the underlying addressing (S2 had a mapping
>                 for the SID for S3, S3 had a mapping for the SID
>                 corresponding to S6, S6 had a mapping for the SID
>                 corresponding to R1 etc)
> 
>                 Then we sent some packets - and the test was entirely
>                 successful.
> 
>                 What this effectively means is that if two providers
>                 agree to share the SID mappings - it is possible to
>                 steer across one network, out over an open path, and
>                 across a remote network.  Obviously this relies on the
>                 fact that EH's aren't being dropped by intermediate
>                 providers, but this isn't something we're seeing.
> 
>                 Combine this with the BGP signaling draft - and the
>                 SID's can then be signaled between the providers - work
>                 still going on with regards to this for testing
>                 purposes.  Just as a note - there would be no
>                 requirement to share the full SID mapping or topologies
>                 when doing this with BGP - the requirement would be only
>                 to share the relevant SID's necessary for the steering.
> 
>                 I can say from our side - with various other providers -
>                 this is something that we see *immense* use case for -
>                 for a whole host of reasons.
> 
>                 Thanks
> 
>                 Andrew
> 
> 
>                 _______________________________________________
>                 spring mailing list
>                 spring@ietf..org <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/Spring
>                 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/Spring__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnrF1wu_DoXwIdf$>
> 
>                 _______________________________________________
>                 spring mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/spring
>                 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnrF1wu_Ll7ej5P$>
> 
> 
> 
>         _______________________________________________
> 
>         spring mailing list
> 
>         [e-mail]  <mailto:[e-mail]>
> 
>         https://www.ietf.org/mailman/listinfo/spring
> 
> ------------------------------------------------------------------------
> 
> */External Email:/*/Please use caution when opening links and 
> attachments / /*/Courriel externe:/*/Soyez prudent avec les liens et 
> documents joints /
> 
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>