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 <[email protected]>, 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) <[email protected]> > > Sent: Monday, September 23, 2019 10:14 PM > > To: Ron Bonica <[email protected]>; Jeff Tantsura > > <[email protected]> > > Cc: SING Team <[email protected]>; EXT - [email protected] > > <[email protected]>; SPRING WG List <[email protected]> > > 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:[email protected]] > > Sent: Monday, September 23, 2019 10:45 PM > > To: Chengli (Cheng Li) <[email protected]>; Jeff Tantsura > > <[email protected]> > > Cc: SING Team <[email protected]>; EXT - [email protected] > > <[email protected]>; SPRING WG List <[email protected]> > > 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) <[email protected]> > > Sent: Sunday, September 22, 2019 12:01 AM > > To: Ron Bonica <[email protected]>; Jeff Tantsura > > <[email protected]> > > Cc: SING Team <[email protected]>; EXT - [email protected] > > <[email protected]>; SPRING WG List <[email protected]> > > 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: [email protected] > > From: Ron Bonica<[email protected]> > > To: Jeff Tantsura<[email protected]>;Chengli (Cheng > > Li)<[email protected]> > > Cc: SING Team<[email protected]>;EXT - > > daniel.bernier<[email protected]>;SPRING WG List<[email protected]> > > 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 <[email protected]> > > Sent: Saturday, September 21, 2019 4:32 PM > > To: Chengli (Cheng Li) <[email protected]>; Ron Bonica > > <[email protected]> > > Cc: SING Team <[email protected]>; EXT - [email protected] > > <[email protected]>; SPRING WG List <[email protected]> > > 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 <[email protected]>, 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 <[email protected]> On Behalf Of Jeff Tantsura > > > Sent: Thursday, September 19, 2019 10:53 PM > > > To: Chengli (Cheng Li) <[email protected]> > > > Cc: SING Team <[email protected]>; EXT - > > > [email protected] <[email protected]>; SPRING WG List > > > <[email protected]> > > > 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) <[email protected]> > > > 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:[email protected]] On Behalf Of Bernier, > > > > Daniel > > > > Sent: Thursday, September 19, 2019 11:36 PM > > > > To: SING Team <[email protected]> > > > > Cc: 'SPRING WG List' <[email protected]> > > > > 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" > > > > <[email protected] on behalf of [email protected]> > > > > 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/Spring > > > > _______________________________________________ > > > > spring mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
