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

From: SING Team <[email-masked]>
Date: Thu, 19 Sep 2019 23:15:06 +0800

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-masked]  https://www.ietf.org/mailman/listinfo/Spring

---

From: "Bernier, Daniel" <[email-masked]>
Date: Thu, 19 Sep 2019 15:36:11 +0000

+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-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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:[email-masked]> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/Spring

---

From: "Bernier, Daniel" <[email-masked]>
Date: Thu, 19 Sep 2019 15:41:41 +0000

Or PPSIs

On 2019-09-19, 11:36 AM, "spring on behalf of Bernier, Daniel" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 20 Sep 2019 02:49:26 +0000

+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-masked]] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team <[email-masked]>
Cc: 'SPRING WG List' <[email-masked]>
Subject: Re: [spring] A note on CRH and on going testing

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 19 Sep 2019 19:53:10 -0700

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-masked]> wrote:
> 
> +1.
>  
> On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" <[email-masked] on behalf of [email-masked]> wrote:
>  
> Hi Andrew,
> 
> On 09/19/2019 17:49, Andrew Alston wrote:
> Hi Guys, 
> 
> [email-masked] 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 20 Sep 2019 02:56:10 +0000

Happy to hear that, many thanks Jeff. I think many people are/ will be aware of it.   :)

Regards,
Cheng

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Friday, September 20, 2019 10:53 AM
To: Chengli (Cheng Li) <[email-masked]>
Cc: Bernier, Daniel <[email-masked]>; SING Team <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] A note on CRH and on going testing

Regards,
Jeff

On Sep 19, 2019, at 19:49, Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>> wrote:
+1.

Cheng

From: spring [mailto:[email-masked]] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team <[email-masked]<mailto:[email-masked]>>
Cc: 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A note on CRH and on going testing

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

---

From: Ron Bonica <[email-masked]>
Date: Fri, 20 Sep 2019 18:09:39 +0000

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-masked]> On Behalf Of Jeff Tantsura
Sent: Thursday, September 19, 2019 10:53 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: SING Team <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]>
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

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

+1

Encap with Binding SID to avoid inter-domain mapping + I don't need to have some sort of inter-domain alignment of PSSIs

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

_______________________________________________
spring mailing list
spring@ietf..org<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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$>

---

From: SING Team <[email-masked]>
Date: Sat, 21 Sep 2019 11:46:18 +0800

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-masked]> On Behalf Of Jeff Tantsura Sent: Thursday, September 19, 2019 10:53 PM To: Chengli (Cheng Li) <[email-masked]> Cc: SING Team <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]> 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-masked]> 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-masked]] On Behalf Of Bernier, Daniel Sent: Thursday, September 19, 2019 11:36 PM To: SING Team <[email-masked]> Cc: 'SPRING WG List' <[email-masked]> 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-masked] on behalf of [email-masked]> 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  spring@ietf..org  https://www.ietf.org/mailman/listinfo/Spring   _______________________________________________ spring mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spring

---

From: Ron Bonica <[email-masked]>
Date: Sat, 21 Sep 2019 18:09:30 +0000

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 information required to compose the binding tunnel
  *   Add a few TLVs to the IGPs to distribute the above-mentioned information

Now, we explore whether it is possible achieve the same effect without defining a new SID type.....

We agree that when an SRv6+ ingress node receives a packet, it can expose that packet to policy. Policy contains match conditions and actions. If the packet satisfies a policy's match conditions, its actions will be executed and its actions may include encapsulating the packet in an IPv6 header.

Policy can be applied recursively. Assume that a packet traverses the following SRv6+ path:

  *   S1 -> S2 -> S3

As the packet enters or traverses Segment S1->S2, the outermost IPv6 address is 2001:db8::1. But somewhere along that path, either at the ingress node or at a transit node, the packet is exposed to policy. Policy matches on the destination address 2001:db8::1 and causes the packet to be encapsulated in yet another SRv6+ tunnel that traverses the following path:

  *   S2A -> S2B -> S2C

The IPv6 address 2001:db8::1 represents a real interface in S3. But it is also the object of a match condition.

                                                                                      Ron

BTW, What does S.I.N.G. stand for? I'm always happy to see students and researchers participating in the IETF !

Juniper Business Use Only
From: SING Team <[email-masked]>
Sent: Friday, September 20, 2019 11:46 PM
To: Ron Bonica <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]>
Subject: 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 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

[Image removed by sender.]
Moonlight Thoughts
SING Team. Guangzhou, China

Signature is customized by Netease Mail Master<https://urldefense.com/v3/__https:/mail.163.com/dashi/dlpro.html?from=mail88__;!8WoA6RjC81c!WGBJP_h3_h-Z3srdMIVg-12_kYbDFVeulK8cLVC_ptBGpDcDP3zO11EVuONBRcme$>
On 09/21/2019 02:09, Ron Bonica<mailto:[email-masked]> wrote:
Hi Jeff,

  *   SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 21 Sep 2019 13:31:46 -0700

Hi Ron,

Thanks for your comments, exactly, BSID MPLS label = CRH value :)

Cheers,
Jeff
On Sep 20, 2019, 11:09 AM -0700, Ron Bonica <[email-masked]>, wrote:
> • SID: 123
> • IPv6 address: 2001:db8::1
> • SID type: prefix SID
>
>
> > spring@ietf..org

---

From: Ron Bonica <[email-masked]>
Date: Sat, 21 Sep 2019 20:37:00 +0000

Jeff,

After an off-line conversation with the SRv6+ implementors, we decided that it would be trivial to add a binding SID to SRv6+. So, we will do that in the next version of the draft.

In keeping with RFC 8200, it will prepend only. Since the CRH is short, insertion is not needed.

                                                                                                       Ron

Juniper Business Use Only
From: Jeff Tantsura <[email-masked]>
Sent: Saturday, September 21, 2019 4:32 PM
To: Chengli (Cheng Li) <[email-masked]>; Ron Bonica <[email-masked]>
Cc: SING Team <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]>
Subject: RE: [spring] A note on CRH and on going testing

Hi Ron,

Cheers,
Jeff
On Sep 20, 2019, 11:09 AM -0700, Ron Bonica <[email-masked]<mailto:[email-masked]>>, wrote:
Hi Jeff,

  *   SID: 123

                                                           Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeff Tantsura
Sent: Thursday, September 19, 2019 10:53 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>
Cc: SING Team <[email-masked]<mailto:[email-masked]>>; EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A note on CRH and on going testing

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sun, 22 Sep 2019 04:00:54 +0000

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 it pollutes the architecture.

If yes, what’s the standard for an Interface IPv6 address?

Thanks for confirming that BSID is needed in CRH. I totally agree with you.

Best regards,
Cheng

________________________________
李呈 Cheng Li
Email: [email-masked]<mailto:[email-masked]>

From: Ron Bonica<[email-masked]<mailto:[email-masked]>>
To: Jeff Tantsura<[email-masked]<mailto:[email-masked]>>;Chengli (Cheng Li)<[email-masked]<mailto:[email-masked]>>
Cc: SING Team<[email-masked]<mailto:[email-masked]>>;EXT - daniel.bernier<[email-masked]<mailto:[email-masked]>>;SPRING WG List<[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] A note on CRH and on going testing
Time: 2019-09-22 04:37:17

Jeff,

                                                                                                       Ron

Hi Ron,

Cheers,
Jeff

  *   SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

---

From: Ron Bonica <[email-masked]>
Date: Mon, 23 Sep 2019 14:45:14 +0000

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 topological instruction, found in the CRH. Like all topological instructions, it will identify an SFIB entry.

There will be a new SFIB entry type that will contain the following information:

  *   An IPv6 Destination Address (to be used in the outer IPv6 header)
  *   A list of SIDs (to be used in the CRH
                                                                 Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica <[email-masked]>; Jeff Tantsura <[email-masked]>
Cc: SING Team <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]>
Subject: RE: [spring] A note on CRH and on going testing

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

Juniper Business Use Only
From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, September 21, 2019 4:32 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: SING Team <[email-masked]<mailto:[email-masked]>>; EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] A note on CRH and on going testing

Hi Ron,

Cheers,
Jeff

  *   SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew