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-boun...@ietf.org> On Behalf Of Jeff Tantsura
Sent: Thursday, September 19, 2019 10:53 PM
To: Chengli (Cheng Li) <chengl...@huawei.com>
Cc: SING Team <s.i.n.g.team.0...@gmail.com>; EXT - daniel.bern...@bell.ca
<daniel.bern...@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)
<chengl...@huawei.com<mailto:chengl...@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-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<mailto:s.i.n.g.team.0...@gmail.com>>
Cc: 'SPRING WG List' <spring@ietf.org<mailto: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
spr...@ietf..org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/Spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/Spring__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnrF1wu_DoXwIdf$>
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnrF1wu_Ll7ej5P$>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
