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 <rbonica@juniper.net>, 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 <spring-bounces@ietf.org> On Behalf Of Jeff Tantsura
> Sent: Thursday, September 19, 2019 10:53 PM
> To: Chengli (Cheng Li) <chengli13@huawei.com>
> Cc: SING Team <s.i.n.g.team.0810@gmail.com>; EXT - daniel.bernier@bell.ca <daniel.bernier@bell.ca>; SPRING WG List <spring@ietf.org>
> 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) <chengli13@huawei.com> 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:spring-bounces@ietf.org] On Behalf Of Bernier, Daniel
> > Sent: Thursday, September 19, 2019 11:36 PM
> > To: SING Team <s.i.n.g.team.0810@gmail.com>
> > Cc: 'SPRING WG List' <spring@ietf.org>
> > 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" <spring-bounces@ietf.org on behalf of s.i.n.g.team.0810@gmail.com> 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
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring