Re: [spring] SR-MPLS over IPv6？

[Stewart Bryant <[e-mail]>]

On 25/09/2019 22:25, Ron Bonica wrote:
>
> Daniel,
>
> I’m not sure that I agree. The PSSI doesn’t represent per-path 
> information. It represents an instruction to be executed at a segment 
> endpoint.
>
> Ron
>
Like a binding SID?

S

> Juniper Business Use Only
>
> *From:*Bernier, Daniel <[e-mail]>
> *Sent:* Wednesday, September 25, 2019 3:41 PM
> *To:* Jeff Tantsura <[e-mail]>; Ron Bonica 
> <[e-mail]>; Chengli (Cheng Li) <[e-mail]>; 
> Stewart Bryant <[e-mail]>
> *Cc:* SPRING WG List <[e-mail]>; SING Team 
> <[e-mail]>
> *Subject:* RE: [spring] SR-MPLS over IPv6？
>
> 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] <mailto:[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
>         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!TzHvGjXYPTnuyBAGRwf9KfKRH1LUVmYkhhBuJYRHS9B9ph5WnPb4g1yFdLGjy2OK$>
>
> ------------------------------------------------------------------------
>
> */External Email:/*/Please use caution when opening links and 
> attachments / /*/Courriel externe:/*/Soyez prudent avec les liens et 
> documents joints /
>