Re: [spring] SR-MPLS over IPv6？

[Jeff Tantsura <[e-mail]>]

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]>
> > 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
> >
> > 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]>; Jeff Tantsura <[e-mail]>
> > Cc: SING Team <[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]>; 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]>; 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]>; 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]] On Behalf Of Bernier, Daniel
> > > > Sent: Thursday, September 19, 2019 11:36 PM
> > > > To: SING Team <[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 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
> > > > https://www.ietf.org/mailman/listinfo/Spring
> > > > _______________________________________________
> > > > spring mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/spring
> >
> > _______________________________________________
> > spring mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spring