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

Reply via email to