Hi Ron, Yes I believe both Binding SID is an important design for inter-domain
signaling, and it is easy to add some mechanisms for SRv6+ to achieve similar
function of Binding SID. :) But I’m not sure if it is feasible to bind one
IPv6 address to ‘BSID’ in SRv6+, because as shown in draft(spring-srv6-plus):
“In SRv6+, an IPv6 address always represents a network interface”, and not
represents an instruction/function on a node as SRv6 does. And, as the way you
presented, interface IPv6 address 2001:db8::1 is mapped with SID 123, and bind
to one SRv6+ tunnel. So, does it mean if we need to advertise many tunnels
outside at one border router, we need to initialize many virtual
interfaces(e.g. loopback) in the router? If does, I’m not sure this is a good
idea to achieve inter-domain service tunnel signaling with security. Because in
contrast to SRv6, it just need to simply add one route/sr-policy. How do you
think? :) Best regards, SING Team Moonlight Thoughts SING Team. Guangzhou,
China Signature is customized by Netease Mail Master On 09/21/2019 02:09, Ron
Bonica 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
