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
