+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-boun...@ietf.org] On Behalf Of Bernier, Daniel Sent: Thursday, September 19, 2019 11:36 PM To: SING Team <s.i.n.g.team.0...@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-boun...@ietf.org<mailto:spring-boun...@ietf.org> on behalf of s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@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<mailto:andrew.als...@liquidtelecom.com> 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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/Spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
