Re: [spring] A note on CRH and on going testing

Cheng, In SRv6+, it would be very difficult to pollute the architecture because: * A SID is either 16-or 32-bits long * An IPv6 address is 128-bits long * Therefore, it is impossible to copy a SID to an IPv6 address or an IPv6 address to a SID The binding SID will be a 16-or 32-bit

Re: [spring] A note on CRH and on going testing

Hi Ron, Good to hear that. Looking forward to seeing it in the next revision. But I am curious that is a bind SID in CRH an interface IPv6 address only without any other semantics? Just like the other SIDs you mentioned in CRH. If not, this binding SID should not be introduced in to CRH since

Re: [spring] A note on CRH and on going testing

Hi S.I.N.G. Team, Good to meet you! Let's address the issue in two parts First, we agree that it would be easy do define a binding SID in SRv6+. We would simply mimic the strategy used by SR-MPLS. That is: * Define a new SID type * Define a new SFIB type that contains all of the

Re: [spring] A note on CRH and on going testing

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

Re: [spring] A note on CRH and on going testing

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

Re: [spring] A note on CRH and on going testing

Happy to hear that, many thanks Jeff. I think many people are/ will be aware of it. :) Regards, Cheng From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] Sent: Friday, September 20, 2019 10:53 AM To: Chengli (Cheng Li) Cc: Bernier, Daniel ; SING Team ; SPRING WG List Subject: Re:

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) wrote: > > +1. > > As I mentioned before, Binding SID is not only for shortening SID list. > We should see the

Re: [spring] A note on CRH and on going testing

+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

Re: [spring] A note on CRH and on going testing

Or PPSIs On 2019-09-19, 11:36 AM, "spring on behalf of Bernier, Daniel" mailto:spring-boun...@ietf.org> on behalf of daniel.bern...@bell.ca> wrote: +1 This is what we did on our multi-cloud trials. Encap with Binding SID to avoid inter-domain mapping + I don’t

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" mailto:spring-boun...@ietf.org> on behalf of

Re: [spring] A note on CRH and on going testing

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

[spring] A note on CRH and on going testing

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