Re: [spring] SR-MPLS over IPv6？

[Stewart Bryant <[e-mail]>]

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]>
> *Sent:* Monday, September 23, 2019 10:14 PM
> *To:* Ron Bonica <[e-mail]>; Jeff Tantsura 
> <[e-mail]>
> *Cc:* SING Team <[e-mail]>; EXT - 
> [e-mail] <[e-mail]>; SPRING WG List 
> <[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]
> https://www.ietf.org/mailman/listinfo/spring