Re: [spring] SR-MPLS over IPv6？

["Bernier, Daniel" <[e-mail]>]

Ah but Joel, 

As was debated over the mailing list, if I have multiple paths (i.e. unidirectional PPSIs) that go across different PSSIs on intermediate nodes each of these intermediate nodes needs to figure out which PSSI to apply before sending to the node next in the forwarding path.

And since these PSSIs are not all carried from source, this requires state.

________________________________________
From: Joel M. Halpern <[e-mail]>
Sent: Wednesday, September 25, 2019 3:50 PM
To: Bernier, Daniel
Cc: SPRING WG List
Subject: [EXT]Re: [spring] SR-MPLS over IPv6？

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
>
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents jointsA