Re: [spring] SR-MPLS over IPv6？

[Mark Smith <[e-mail]>]

Supposedly "Segment Routing" is an architecture according to RFC 8402, so
anything that satisfies the architecture can use the term "Segment Routing".

If SPRING want to play that game, then stop using "IPv6", because a number
of proposals blatantly and purposely don't comply with Internet Standard
RFC 8200, and other Standards Track RFCs like RFC 4291.

A proprietary variant of IPv6 isn't IPv6, it's something else.

On Fri, 27 Sep 2019, 02:17 Zafar Ali (zali), <[e-mail]> wrote:

> Hi Ron,
>
>
>
> I agree with Dan, Jeff and others that the name should NOT create
> confusion with an already established technology (SR).
>
> The name should reflect the design and the spirit of your proposal.
>
>
>
> To try to help you differentiate your solution, may I propose
>
>
>
> *“LIMPH: Label Indirection with MultiPle Headers”*
>
>
>
> Here is the rationale:
>
>    - A new system of mapping IDs to IP addresses is being introduced (btw
>    we’ve had MPLS for doing that for ages now and so is this really something
>    different?)
>    - Then these mapped IDs are spread across multiple IPv6 extension
>    headers (introducing 2 new RHs and 2 new DOHs) thereby introducing more
>    complexity in IPv6 processing. We have simpler existing solutions
>    [draft-ietf-mpls-sr-over-ip] i.e. {IPv6 NH = UDP, 8 byte UDP header, stack
>    of mapping IDs aka MPLS labels}.
>    - As Dan mentioned, there is the PSSI for implementing “limited
>    service chaining” which seems very similar to RFC8595 and is stateful and
>    “encodes a logical representation” of an NSH albeit with a simpler
>    encapsulation and without TLVs just as in RFC8595.
>
> Let’s your individual submissions not continue to cause confusion by
> making use of a marketing name that drags on the coattails of SRv6 (which
> has been adopted at the IETF and deployed by the industry).
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <[e-mail]> on behalf of "Bernier, Daniel" <
> [e-mail]>
> *Date: *Wednesday, September 25, 2019 at 3:41 PM
> *To: *Jeff Tantsura <[e-mail]>, Ron Bonica <rbonica=
> [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]> 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]> <[e-mail]>
> *Sent:* Monday, September 23, 2019 10:14 PM
> *To:* Ron Bonica <[e-mail]> <[e-mail]>; Jeff
> Tantsura <[e-mail]> <[e-mail]>
> *Cc:* SING Team <[e-mail]>
> <[e-mail]>; EXT - [e-mail]
> <[e-mail]> <[e-mail]>; SPRING WG List
> <[e-mail]> <[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] <[e-mail]>]
> *Sent:* Monday, September 23, 2019 10:45 PM
> *To:* Chengli (Cheng Li) <[e-mail]>; Jeff Tantsura <
> [e-mail]>
> *Cc:* SING Team <[e-mail]
> <[e-mail]>>; EXT - [e-mail] <
> [e-mail]>; SPRING WG List <[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]>
> *Sent:* Sunday, September 22, 2019 12:01 AM
> *To:* Ron Bonica <[e-mail]>; Jeff Tantsura <
> [e-mail]>
> *Cc:* SING Team <[e-mail]
> <[e-mail]>>; EXT - [e-mail] <
> [e-mail]>; SPRING WG List <[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]
>
> *From:* Ron Bonica<[e-mail]>
>
> *To:* Jeff Tantsura<[e-mail]>;Chengli (Cheng Li)<
> [e-mail]>
>
> *Cc:* SING Team<[e-mail]>;EXT - daniel.bernier<
> [e-mail]>;SPRING WG List<[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]>
> *Sent:* Saturday, September 21, 2019 4:32 PM
> *To:* Chengli (Cheng Li) <[e-mail]>; Ron Bonica <
> [e-mail]>
> *Cc:* SING Team <[e-mail]
> <[e-mail]>>; EXT - [e-mail] <
> [e-mail]>; SPRING WG List <[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]>, 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]> *On Behalf Of* Jeff Tantsura
> *Sent:* Thursday, September 19, 2019 10:53 PM
> *To:* Chengli (Cheng Li) <[e-mail]>
> *Cc:* SING Team <[e-mail]
> <[e-mail]>>; EXT - [e-mail] <
> [e-mail]>; SPRING WG List <[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]>
> 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] <[e-mail]>] *On
> Behalf Of* Bernier, Daniel
> *Sent:* Thursday, September 19, 2019 11:36 PM
> *To:* SING Team <[e-mail]
> <[e-mail]>>
> *Cc:* 'SPRING WG List' <[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] on behalf of [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 <[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 <[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]
> 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
>
> ------------------------------
>
> *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
>