Subject: Re: [spring] SR-MPLS over IPv6？

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 24 Sep 2019 02:13:53 +0000

Oh, I misunderstood the BSID in CRH in last email, sorry for that.

Yes, the SID is not an IPv6 address in CRH, but a 16/32 bit value like MPLS label.

Therefore, IMHO, it may not comply with RFC8402: https://tools.ietf.org/html/rfc8402#section-3.1.3

If possible, I suggest to change the name of SRv6+, since it is not SRv6 based. Something like SR-MPLS over IPv6 maybe better?

Thanks,
Cheng

From: Ron Bonica [mailto:[email-masked]]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) <[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

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]<mailto:[email-masked]>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[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,

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,

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]<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,

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

Cheers,
Jeff
On Sep 20, 2019, 11:09 AM -0700, Ron Bonica <[email-masked]<mailto:[email-masked]>>, 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]<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

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]<mailto:[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]<mailto:[email-masked]>>
Cc: 'SPRING WG List' <[email-masked]<mailto:[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]<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
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: Ron Bonica <[email-masked]>
Date: Tue, 24 Sep 2019 04:01:18 +0000

Cheng,

I have no problem with changing the name. SR-MPLS over IPv6 may not be appropriate, because MPLS is not part of the solution.

Something like SR-extensible-6 or SR-compressed-6 might work.

                                                               Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]>
Sent: Monday, September 23, 2019 10:14 PM
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] SR-MPLS over IPv6？

Therefore, IMHO, it may not comply with RFC8402: https://tools.ietf.org/html/rfc8402#section-3.1.3<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-3.1.3__;Iw!8WoA6RjC81c!WoPYW9IpnDYjcdhli0b80_-KyrOIBYFAZfip_NxPLB1-Bt7oHjt8uGU68K49j2yk$>

Thanks,
Cheng

To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>

Cheng,

  *   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.

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

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

Hi Ron,

Cheers,
Jeff

  *   SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Sep 2019 13:39:40 +0100

I agree.

Inclusion of the term MPLS would cause confusion with 
draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The 
design decribed in draft-ietf-mpls-sr-over-ip works over both IPv4 and 
IPv6. Also course, as Ron states, such a name is not a true refelction 
of the design.

- Stewart

On 24/09/2019 05:01, Ron Bonica wrote:
>
> Cheng,
>
> I have no problem with changing the name. SR-MPLS over IPv6 may not be 
> appropriate, because MPLS is not part of the solution.
>
> *From:*Chengli (Cheng Li) <[email-masked]>
> *Sent:* Monday, September 23, 2019 10:14 PM
> *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] SR-MPLS over IPv6？
>
> Therefore, IMHO, it may not comply with RFC8402: 
> https://tools.ietf.org/html/rfc8402#section-3.1.3 
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*section-3.1.3__;Iw!8WoA6RjC81c!WoPYW9IpnDYjcdhli0b80_-KyrOIBYFAZfip_NxPLB1-Bt7oHjt8uGU68K49j2yk$>
>
> If possible, I suggest to change the name of SRv6+, since it is not 
> SRv6 based. Something like SR-MPLS over IPv6 maybe better?
>
> Thanks,
>
> Cheng
>
> *From:*Ron Bonica [mailto:[email-masked]]
> *Sent:* Monday, September 23, 2019 10:45 PM
> *To:* Chengli (Cheng Li) <[email-masked] 
> <mailto:[email-masked]>>; Jeff Tantsura <[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
>
> Cheng,
>
> 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.
>
> *From:* Chengli (Cheng Li) <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Sunday, September 22, 2019 12:01 AM
> *To:* Ron Bonica <[email-masked] <mailto:[email-masked]>>; 
> Jeff Tantsura <[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,
>
> 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.
>
> ------------------------------------------------------------------------
>
> 李呈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,
>
> 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.
>
> *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,
>
>     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.
>
>     *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
>
>     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] <mailto:[email-masked]>> wrote:
>
>         +1.
>
>         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]
>         <mailto:[email-masked]>>
>         *Cc:* 'SPRING WG List' <[email-masked] <mailto:[email-masked]>>
>         *Subject:* Re: [spring] A note on CRH and on going testing
>
>         +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
>
>         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,
>
>         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.
>
>         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)
>
>         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@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$>
>
>         [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$>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 25 Sep 2019 14:43:12 +0200

Agree with Stuart.
SRinUDP is a well defined solution, let’s not mix things.

Cheers,
Jeff
On Sep 25, 2019, 2:39 PM +0200, Stewart Bryant <[email-masked]>, wrote:
> I agree.
>
> Inclusion of the term MPLS would cause confusion with draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The design decribed in draft-ietf-mpls-sr-over-ip works over both IPv4 and IPv6. Also course, as Ron states, such a name is not a true refelction of the design.
> - Stewart
> > Cc: SING Team <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]>
> > • 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
> >
> > • An IPv6 Destination Address (to be used in the outer IPv6 header)
> > • A list of SIDs (to be used in the CRH
> >
> >                                                                  Ron
> >
> >
> >
> >
> > Cc: SING Team <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]>
> > Email: [email-masked]
> > From: Ron Bonica<[email-masked]>
> > To: Jeff Tantsura<[email-masked]>;Chengli (Cheng Li)<[email-masked]>
> > Cc: SING Team<[email-masked]>;EXT - daniel.bernier<[email-masked]>;SPRING WG List<[email-masked]>
> > From: Jeff Tantsura <[email-masked]>
> > 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]>
> > On Sep 20, 2019, 11:09 AM -0700, Ron Bonica <[email-masked]>, wrote:
> > > Hi Jeff,
> > >
> > > • SID: 123
> > > • IPv6 address: 2001:db8::1
> > > • SID type: prefix SID
> > >
> > >
> > > From: spring <[email-masked]> On Behalf Of Jeff Tantsura
> > > To: Chengli (Cheng Li) <[email-masked]>
> > > Cc: SING Team <[email-masked]>; EXT - [email-masked] <[email-masked]>; SPRING WG List <[email-masked]>
> > > On Sep 19, 2019, at 19:49, Chengli (Cheng Li) <[email-masked]> wrote:
> > > > +1.
> > > >
> > > > To: SING Team <[email-masked]>
> > > > Cc: 'SPRING WG List' <[email-masked]>
> > > > 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,
> > > >
> > > > spring@ietf..org

---

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

Hi Ron,

Similarly I would refrain from using the SR acronym since a key characteristic of the SR architecture as per RFC8402 is statelessness.

As per current SRv6+ documents, state is required for an intermediate node to add the relevant next PSSIs in DOH. This is whether they are domain-wide defined or with local significance (i.e. prepending short-SID).

Cheers,

Dan B

On 2019-09-25, 8:43 AM, "Jeff Tantsura" <[email-masked]<mailto:[email-masked]>> wrote:

Agree with Stuart.

Cheers,
Jeff

I agree.

- Stewart

                                                               Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]><mailto:[email-masked]>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <[email-masked]><mailto:[email-masked]>; Jeff Tantsura <[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] SR-MPLS over IPv6？

Thanks,
Cheng

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]>>

Cheng,

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]>>

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

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]>>

Hi Ron,

Cheers,
Jeff

·         SID: 123
·         IPv6 address: 2001:db8::1
·         SID type: prefix SID

                                                           Ron

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]>>

Regards,
Jeff

Cheng

To: SING Team <[email-masked]<mailto:[email-masked]>>

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

spring mailing list

________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Sep 2019 15:50:14 -0400

SR is Stateless in the sense of not having per-path state.  It is not 
stateless in a general sense, since otherwise MPLS-SR would not be SR 
(it needs label state).  So I think we are reading 8402 differently.

We can let the marketing folks fight it out in the marketplace.

Yours,
Joel

On 9/25/2019 3:41 PM, Bernier, Daniel wrote:
> Hi Ron,
> 
> Similarly I would refrain from using the SR acronym since a key 
> characteristic of the SR architecture as per RFC8402 is statelessness.
> 
> As per current SRv6+ documents, state is required for an intermediate 
> node to add the relevant next PSSIs in DOH. This is whether they are 
> domain-wide defined or with local significance (i.e. prepending short-SID).
> 
> Cheers,
> 
> Dan B
> 
>     design decribed in draft-ietf-mpls-sr-over-ip works over both IPv4
>     and IPv6. Also course, as Ron states, such a name is not a true
>     refelction of the design.
> 
>     - Stewart
> 
>         I have no problem with changing the name. SR-MPLS over IPv6 may
>         not be appropriate, because MPLS is not part of the solution.
> 
>         *From:* Chengli (Cheng Li) <[email-masked]>
>         <mailto:[email-masked]>
>         *To:* Ron Bonica <[email-masked]>
>         <mailto:[email-masked]>; Jeff Tantsura
>         <[email-masked]> <mailto:[email-masked]>
>         *Cc:* SING Team <[email-masked]>
>         <mailto:[email-masked]>; EXT -
>         <[email-masked]> <mailto:[email-masked]>; SPRING
>         WG List <[email-masked]> <mailto:[email-masked]>
>         If possible, I suggest to change the name of SRv6+, since it is
>         not SRv6 based. Something like SR-MPLS over IPv6 maybe better?
> 
>         Thanks,
> 
>         Cheng
> 
>         *From:* Ron Bonica [mailto:[email-masked]]
>         <mailto:[email-masked]>>; Jeff Tantsura
>         <[email-masked] <mailto:[email-masked]>>
>         -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.
> 
>         -An IPv6 Destination Address (to be used in the outer IPv6 header)
> 
>         -A list of SIDs (to be used in the CRH
> 
>                                                                 
>                   Ron
> 
>         *To:* Ron Bonica <[email-masked]
>         <mailto:[email-masked]>>; Jeff Tantsura
>         <[email-masked] <mailto:[email-masked]>>
>         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.
> 
>         *From:* Ron Bonica<[email-masked] <mailto:[email-masked]>>
> 
>         *To:* Jeff Tantsura<[email-masked]
>         *Cc:* SING Team<[email-masked]
>         *Time:* 2019-09-22 04:37:17
> 
>         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.
> 
>             However, there is another way to get exactly the same
>             behavior on the forwarding plane without adding a new SID type.
> 
>             ·SID: 123
>             ·IPv6 address: 2001:db8::1
> 
>             ·SID type: prefix SID
> 
>             <[email-masked] <mailto:[email-masked]>>;
>             SPRING WG List <[email-masked] <mailto:[email-masked]>>
>             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
> 
>                 *From:* spring [mailto:[email-masked]] *On
>                 Behalf Of* Bernier, Daniel
>                 Encap with Binding SID to avoid inter-domain mapping + I
>                 don’t need to have some sort of inter-domain alignment
>                 of PSSIs
> 
>                 Dan
> 
>                 <[email-masked]
>                 <mailto:[email-masked]> on behalf of
>                 [email-masked]
>                 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.
> 
>                 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)
> 
>                 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
> 
> 
> */External Email:/*/Please use caution when opening links and 
> attachments / /*/Courriel externe:/*/Soyez prudent avec les liens et 
> documents joints /
> 
>

---

From: "Bernier, Daniel" <[email-masked]>
Date: Wed, 25 Sep 2019 20:06:51 +0000

Ah but Joel, 

As was debated over the mailing list, if I have multiple paths (i.e. unidirectional PPSIs) that go across different PSSIs on intermediate nodes each of these intermediate nodes needs to figure out which PSSI to apply before sending to the node next in the forwarding path.

And since these PSSIs are not all carried from source, this requires state.

________________________________________
From: Joel M. Halpern <[email-masked]>
Sent: Wednesday, September 25, 2019 3:50 PM
To: Bernier, Daniel
Cc: SPRING WG List
Subject: [EXT]Re: [spring] SR-MPLS over IPv6？

Yours,
Joel

>         Thanks for confirming that BSID is needed in CRH. I totally
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents jointsA

---

From: Ron Bonica <[email-masked]>
Date: Wed, 25 Sep 2019 21:25:05 +0000

Daniel,

I’m not sure that I agree. The PSSI doesn’t represent per-path information. It represents an instruction to be executed at a segment endpoint.

                                                      Ron

Juniper Business Use Only
From: Bernier, Daniel <[email-masked]>
Sent: Wednesday, September 25, 2019 3:41 PM
To: Jeff Tantsura <[email-masked]>; Ron Bonica <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: SPRING WG List <[email-masked]>; SING Team <[email-masked]>
Subject: RE: [spring] SR-MPLS over IPv6？

Hi Ron,

Cheers,

Dan B

Agree with Stuart.

Cheers,
Jeff
On Sep 25, 2019, 2:39 PM +0200, Stewart Bryant <[email-masked]<mailto:[email-masked]>>, wrote:

I agree.

- Stewart

                                                               Ron

Thanks,
Cheng

Cheng,

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

Hi Ron,

Cheers,
Jeff

*        SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!TzHvGjXYPTnuyBAGRwf9KfKRH1LUVmYkhhBuJYRHS9B9ph5WnPb4g1yFdLGjy2OK$>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 25 Sep 2019 21:46:53 +0000

Daniel,

In you message, do you really mean PPSIs? Or when you say PPSI, are you really referring to topological instructions?

                                                                                                                 Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Bernier, Daniel
Sent: Wednesday, September 25, 2019 4:07 PM
To: Joel M. Halpern <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Ah but Joel, 

SR is Stateless in the sense of not having per-path state.  It is not stateless in a general sense, since otherwise MPLS-SR would not be SR (it needs label state).  So I think we are reading 8402 differently.

Yours,
Joel

On 9/25/2019 3:41 PM, Bernier, Daniel wrote:
>         https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8402*section-3.1.3__;Iw!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKTovGi8h8S5bZxBkXNLjq$ 
>         
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402*sectio
> n-3.1.3__;Iw!8WoA6RjC81c!WoPYW9IpnDYjcdhli0b80_-KyrOIBYFAZfip_NxPLB1-B
> t7oHjt8uGU68K49j2yk$>
>
>                 https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/Spring__;!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKTovGi8h8S5bZxDonQAID$ 
>                 
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/Spri
> ng__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnr
> F1wu_DoXwIdf$>
>
>                 https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKTovGi8h8S5bZxBSWvl_l$ 
>                 
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!U4_s7somKP_KyQ3viBMIcXpk_pTMYlY11nTHMB2b-JTdTLKi9mnr
> F1wu_Ll7ej5P$>
>
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKTovGi8h8
> S5bZxBSWvl_l$
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKTovGi8h8
> S5bZxBSWvl_l$
>
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents jointsA _______________________________________________
spring mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKTovGi8h8S5bZxBSWvl_l$

---

From: "Bernier, Daniel" <[email-masked]>
Date: Thu, 26 Sep 2019 12:29:24 +0000

Ron,

Say I have the following topology (augmenting on Robert's use case) with x Number of VRFs on PE1 or PE2

PE1 -- P1 --  P2 --  P3 --  PE2 
             |         |         |
           SE1   SE2   SE3             

For a single path program, when a packet sourced in a VPN on PE1 needs to talk to a destination at PE2 while traversing SE1 and SE3

- you need a PPSI for PE2 to know what to do when packet arrives at PE2
- you need a PSSI for SE1 that gets swapped for a PSSI for SE3
- You also need the opposite too make it a bidirectional. 

How does SE1 or SE3 know if and what PSSI to apply ? On one direction it adds a  PSSI for SE3, on the return it does not.
What happens if there is another flow between different source and destination VPNs on PE1 and PE2 and need now to go through SE1, SE2, SE3 ? 

From what I gather,  SE1, SE2, SE3 will need to have a state table to figure out what to apply based on source/dest PPSIs plus + the FIB/SFIB mapping.

Cheers,

Dan

________________________________________
From: Ron Bonica <[email-masked]>
Sent: Wednesday, September 25, 2019 5:46 PM
To: Bernier, Daniel; Joel M. Halpern
Cc: SPRING WG List
Subject: [EXT]RE: [spring] SR-MPLS over IPv6？

Daniel,

                                                                                                                 Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Bernier, Daniel
Sent: Wednesday, September 25, 2019 4:07 PM
To: Joel M. Halpern <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Ah but Joel,

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Sep 2019 08:44:34 -0400

I presume there are some aspects of this question that I am not 
understanding.

The basic answer is that if the topology directions (CRH, or for that 
matter SRH) direct the packet to SE1 then SE1 does its job with the packet.
If SE can do multiple jobs, then it probably has multiple IP addresses 
for those different jobs.

If SE1 needs metadata to do its job (a not unreasonable requirement) 
then I suggest using the IETF standardized mechanism, NSH.

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 26 Sep 2019 15:06:09 +0100

The thing that pushes the original SR design into statefulness is 
binding SIDs which require state to be pre-positioned in the network.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 26 Sep 2019 15:06:53 +0100

On 25/09/2019 22:25, Ron Bonica wrote:
>
> Daniel,
>
> I’m not sure that I agree. The PSSI doesn’t represent per-path 
> information. It represents an instruction to be executed at a segment 
> endpoint.
>
> Ron
>
Like a binding SID?

S

> *From:*Bernier, Daniel <[email-masked]>
> *Sent:* Wednesday, September 25, 2019 3:41 PM
> *To:* Jeff Tantsura <[email-masked]>; Ron Bonica 
> <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; 
> Stewart Bryant <[email-masked]>
> *Cc:* SPRING WG List <[email-masked]>; SING Team 
> <[email-masked]>
> On Sep 25, 2019, 2:39 PM +0200, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>>, wrote:
>
>     I agree.
>
>         I have no problem with changing the name. SR-MPLS over IPv6
>         may not be appropriate, because MPLS is not part of the solution.
>
>         <[email-masked]> <mailto:[email-masked]>;
>         SPRING WG List <[email-masked]> <mailto:[email-masked]>
>         Therefore, IMHO, it may not comply with
>         RFC8402:https://tools.ietf.org/html/rfc8402#section-3.1.3
>         If possible, I suggest to change the name of SRv6+, since it
>         is not SRv6 based. Something like SR-MPLS over IPv6 maybe better?
>
>         Thanks,
>
>         Cheng
>
>         -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.
>
>         *From:*Chengli (Cheng Li) <[email-masked]
>         Email:[email-masked] <mailto:[email-masked]>
>
>         *From:*Ron Bonica<[email-masked]
>         *To:*Jeff Tantsura<[email-masked]
>         *Cc:*SING Team<[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,
>
>         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.
>
>          �� Ron
>         *From:*Jeff Tantsura <[email-masked]
>         <mailto:[email-masked]>>; Ron Bonica
>         <[email-masked] <mailto:[email-masked]>>
>         On Sep 20, 2019, 11:09 AM -0700, Ron Bonica
>         <[email-masked] <mailto:[email-masked]>>, 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.
>
>             *From:*spring <[email-masked]
>                 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.
>
>                 *From:*spring [mailto:[email-masked]] *On
>                 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]
>                 inter-domain traffic steering with CRH on both our
>                 DPDK implementation and another implementation.
>
>                 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)
>
>                 SID's can then be signaled between the providers -
>                 work still going on with regards to this for testing
>                 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
>
>
>         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!TzHvGjXYPTnuyBAGRwf9KfKRH1LUVmYkhhBuJYRHS9B9ph5WnPb4g1yFdLGjy2OK$>
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 26 Sep 2019 15:53:29 +0000

Exactly like a binding SID

Ron
Sent from my phone

On Sep 26, 2019, at 10:07 AM, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

                                                      Ron

Like a binding SID?

S

Juniper Business Use Only
From: Bernier, Daniel <[email-masked]><mailto:[email-masked]>
Sent: Wednesday, September 25, 2019 3:41 PM
To: Jeff Tantsura <[email-masked]><mailto:[email-masked]>; Ron Bonica <[email-masked]><mailto:[email-masked]>; Chengli (Cheng Li) <[email-masked]><mailto:[email-masked]>; Stewart Bryant <[email-masked]><mailto:[email-masked]>
Cc: SPRING WG List <[email-masked]><mailto:[email-masked]>; SING Team <[email-masked]><mailto:[email-masked]>
Subject: RE: [spring] SR-MPLS over IPv6？

Hi Ron,

Cheers,

Dan B

Agree with Stuart.

Cheers,
Jeff

I agree.

- Stewart

                                                               Ron

Thanks,
Cheng

Cheng,

Hi Ron,

Best regards,
Cheng

Jeff,

 ��                                                                                                     Ron

Hi Ron,

Cheers,
Jeff

·        SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

spring mailing list

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 26 Sep 2019 16:17:09 +0000

Hi Ron,

I agree with Dan, Jeff and others that the name should NOT create confusion with an already established technology (SR).
The name should reflect the design and the spirit of your proposal.

To try to help you differentiate your solution, may I propose

“LIMPH: Label Indirection with MultiPle Headers”

Here is the rationale:

  *   A new system of mapping IDs to IP addresses is being introduced (btw we’ve had MPLS for doing that for ages now and so is this really something different?)
  *   Then these mapped IDs are spread across multiple IPv6 extension headers (introducing 2 new RHs and 2 new DOHs) thereby introducing more complexity in IPv6 processing. We have simpler existing solutions [draft-ietf-mpls-sr-over-ip] i.e. {IPv6 NH = UDP, 8 byte UDP header, stack of mapping IDs aka MPLS labels}.
  *   As Dan mentioned, there is the PSSI for implementing “limited service chaining” which seems very similar to RFC8595 and is stateful and “encodes a logical representation” of an NSH albeit with a simpler encapsulation and without TLVs just as in RFC8595.
Let’s your individual submissions not continue to cause confusion by making use of a marketing name that drags on the coattails of SRv6 (which has been adopted at the IETF and deployed by the industry).

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of "Bernier, Daniel" <[email-masked]>
Date: Wednesday, September 25, 2019 at 3:41 PM
To: Jeff Tantsura <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, "Chengli (Cheng Li)" <[email-masked]>, Stewart Bryant <[email-masked]>
Cc: SPRING WG List <[email-masked]>, SING Team <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Hi Ron,

Cheers,

Dan B

Agree with Stuart.

Cheers,
Jeff

I agree.

- Stewart

                                                               Ron

Thanks,
Cheng

Cheng,

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

Hi Ron,

Cheers,
Jeff

·         SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

spring mailing list

---

From: Ron Bonica <[email-masked]>
Date: Thu, 26 Sep 2019 18:58:18 +0000

Zafar,

This is a pretty obvious attempt to create backronymn ( https://en.wikipedia.org/wiki/Backronym ) with negative connotations. So, I am not taking it seriously.

(For those who are not native speakers of English, the work “limp” carries negative connotations in  English.)

                                                                                                   Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Thursday, September 26, 2019 12:17 PM
To: EXT - [email-masked] <[email-masked]>; Jeff Tantsura <[email-masked]>; Ron Bonica <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: SPRING WG List <[email-masked]>; SING Team <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Hi Ron,

Here is the rationale:

Thanks

Regards … Zafar

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Bernier, Daniel" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 25, 2019 at 3:41 PM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, "Chengli (Cheng Li)" <[email-masked]<mailto:[email-masked]>>, Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, SING Team <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] SR-MPLS over IPv6？

Hi Ron,

Cheers,

Dan B

Agree with Stuart.

Cheers,
Jeff

I agree.

- Stewart

                                                               Ron

Thanks,
Cheng

Cheng,

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

Hi Ron,

Cheers,
Jeff

*         SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!TfFPXN46U8X4Ofg8HjOZURz2vibZ7xX9VPHPZwePpNpFS4mFSlSluJs8p3X8mteY$>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 26 Sep 2019 23:12:38 +0000

Hi Ron,

“limp” is indeed humorous interpretation! I can see why you would not want to take seriously!

I do confess that I’m not a native English speaker.
I intended it to be pronounced “/limf/” as in the “lymphatic system” due to the distribution of state to nodes in the system.

Thanks

Regards … Zafar

From: Ron Bonica <[email-masked]>
Date: Thursday, September 26, 2019 at 2:58 PM
To: "Zafar Ali (zali)" <[email-masked]>, "EXT - [email-masked]" <[email-masked]>, Jeff Tantsura <[email-masked]>, "Chengli (Cheng Li)" <[email-masked]>, Stewart Bryant <[email-masked]>
Cc: SPRING WG List <[email-masked]>, SING Team <[email-masked]>
Subject: RE: [spring] SR-MPLS over IPv6？

Zafar,

                                                                                                   Ron

Hi Ron,

Here is the rationale:

Thanks

Regards … Zafar

Hi Ron,

Cheers,

Dan B

Agree with Stuart.

Cheers,
Jeff

I agree.

- Stewart

                                                               Ron

Thanks,
Cheng

Cheng,

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

Hi Ron,

Cheers,
Jeff

·         SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

spring mailing list

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 Sep 2019 10:43:19 +1000

Supposedly "Segment Routing" is an architecture according to RFC 8402, so
anything that satisfies the architecture can use the term "Segment Routing".

If SPRING want to play that game, then stop using "IPv6", because a number
of proposals blatantly and purposely don't comply with Internet Standard
RFC 8200, and other Standards Track RFCs like RFC 4291.

A proprietary variant of IPv6 isn't IPv6, it's something else.

On Fri, 27 Sep 2019, 02:17 Zafar Ali (zali), <[email-masked]> wrote:

> Hi Ron,
>
>
>
> I agree with Dan, Jeff and others that the name should NOT create
> confusion with an already established technology (SR).
>
> *“LIMPH: Label Indirection with MultiPle Headers”*
>
>
>
> Here is the rationale:
>
>    - A new system of mapping IDs to IP addresses is being introduced (btw
>    we’ve had MPLS for doing that for ages now and so is this really something
>    different?)
>    - Then these mapped IDs are spread across multiple IPv6 extension
>    headers (introducing 2 new RHs and 2 new DOHs) thereby introducing more
>    complexity in IPv6 processing. We have simpler existing solutions
>    [draft-ietf-mpls-sr-over-ip] i.e. {IPv6 NH = UDP, 8 byte UDP header, stack
>    of mapping IDs aka MPLS labels}.
>    - As Dan mentioned, there is the PSSI for implementing “limited
>    service chaining” which seems very similar to RFC8595 and is stateful and
>    “encodes a logical representation” of an NSH albeit with a simpler
>    encapsulation and without TLVs just as in RFC8595.
>
> Let’s your individual submissions not continue to cause confusion by
> making use of a marketing name that drags on the coattails of SRv6 (which
> has been adopted at the IETF and deployed by the industry).
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <[email-masked]> on behalf of "Bernier, Daniel" <
> [email-masked]>
> *Date: *Wednesday, September 25, 2019 at 3:41 PM
> *To: *Jeff Tantsura <[email-masked]>, Ron Bonica <rbonica=
> [email-masked]>, "Chengli (Cheng Li)" <[email-masked]>,
> *Cc: *SPRING WG List <[email-masked]>, SING Team <
> [email-masked]>
> *Subject: *Re: [spring] SR-MPLS over IPv6？
>
>
>
> Hi Ron,
>
>
>
> As per current SRv6+ documents, state is required for an intermediate node
> to add the relevant next PSSIs in DOH. This is whether they are domain-wide
> defined or with local significance (i.e. prepending short-SID).
>
>
>
> Cheers,
>
>
>
> Dan B
>
>
>
> On 2019-09-25, 8:43 AM, "Jeff Tantsura" <[email-masked]> wrote:
>
>
>
> Agree with Stuart.
>
> draft-ietf-mpls-sr-over-ip, which is entitled SR-MPLS over IP. The design
> decribed in draft-ietf-mpls-sr-over-ip works over both IPv4 and IPv6. Also
> course, as Ron states, such a name is not a true refelction of the design.
>
> - Stewart
>
> *From:* Chengli (Cheng Li) <[email-masked]> <[email-masked]>
> *To:* Ron Bonica <[email-masked]> <[email-masked]>; Jeff
> Tantsura <[email-masked]> <[email-masked]>
> <[email-masked]>; EXT - [email-masked]
> <[email-masked]> <[email-masked]>; SPRING WG List
> <[email-masked]> <[email-masked]>
> If possible, I suggest to change the name of SRv6+, since it is not SRv6
> based. Something like SR-MPLS over IPv6 maybe better?
>
>
>
> Thanks,
>
> Cheng
>
>
>
>
>
> *From:* Ron Bonica [mailto:[email-masked] <[email-masked]>]
> *To:* Chengli (Cheng Li) <[email-masked]>; Jeff Tantsura <
> [email-masked]>
> <[email-masked]>>; EXT - [email-masked] <
> [email-masked]>; SPRING WG List <[email-masked]>
> 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.
>
>
>
> *To:* Ron Bonica <[email-masked]>; Jeff Tantsura <
> [email-masked]>
> <[email-masked]>>; EXT - [email-masked] <
> [email-masked]>; SPRING WG List <[email-masked]>
> 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.
>
> ------------------------------
>
> 李呈 Cheng Li
> *From:* Ron Bonica<[email-masked]>
>
> *To:* Jeff Tantsura<[email-masked]>;Chengli (Cheng Li)<
> [email-masked]>
>
> *Cc:* SING Team<[email-masked]>;EXT - daniel.bernier<
> [email-masked]>;SPRING WG List<[email-masked]>
>
> that it would be trivial to add a binding SID to SRv6+. So, we will do that
> in the next version of the draft.
>
>
>
> *From:* Jeff Tantsura <[email-masked]>
> *To:* Chengli (Cheng Li) <[email-masked]>; Ron Bonica <
> [email-masked]>
> <[email-masked]>>; EXT - [email-masked] <
> [email-masked]>; SPRING WG List <[email-masked]>
> 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.
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of* Jeff Tantsura
> *To:* Chengli (Cheng Li) <[email-masked]>
> <[email-masked]>>; EXT - [email-masked] <
> [email-masked]>; SPRING WG List <[email-masked]>
> There’s number of solutions on the market that extensively use BSID for
> multi-domain as well as multi-layer signaling.
>
>
>
> Regards,
>
> Jeff
>
>
> 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] <[email-masked]>] *On
> <[email-masked]>>
> *Cc:* 'SPRING WG List' <[email-masked]>
> 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,
>
> On 09/19/2019 17:49, Andrew Alston <[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.
>
> 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)
>
> 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@ietf..org <[email-masked]>
> ------------------------------
>
> *External Email:** Please use caution when opening links and attachments
> / **Courriel externe:** Soyez prudent avec les liens et documents joints *

---

From: Ron Bonica <[email-masked]>
Date: Fri, 27 Sep 2019 00:48:09 +0000

Zafar,

I’m sorry. I didn’t realize that you are not a native speaker. Your English is excellent!

Let’s just call it an unfortunate acronym and move on.

                                                                   Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Thursday, September 26, 2019 7:13 PM
To: Ron Bonica <[email-masked]>; EXT - [email-masked] <[email-masked]>; Jeff Tantsura <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: SPRING WG List <[email-masked]>; SING Team <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Hi Ron,

Thanks

Regards … Zafar

From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 26, 2019 at 2:58 PM
To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, "EXT - [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "Chengli (Cheng Li)" <[email-masked]<mailto:[email-masked]>>, Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>, SING Team <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] SR-MPLS over IPv6？

Zafar,

This is a pretty obvious attempt to create backronymn ( https://en.wikipedia.org/wiki/Backronym<https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/Backronym__;!8WoA6RjC81c!VJuk15hJagZWK817yojThqDx6BgYIzYzv-m3DbxSJVYBmP6I4xpk_4v3DT_WdzpX$> ) with negative connotations. So, I am not taking it seriously.

                                                                                                   Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 26, 2019 12:17 PM
To: EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>; SING Team <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] SR-MPLS over IPv6？

Hi Ron,

Here is the rationale:

Thanks

Regards … Zafar

Hi Ron,

Cheers,

Dan B

Agree with Stuart.

Cheers,
Jeff

I agree.

- Stewart

                                                               Ron

Thanks,
Cheng

Cheng,

Hi Ron,

Best regards,
Cheng

Jeff,

                                                                                                       Ron

Hi Ron,

Cheers,
Jeff

*         SID: 123

                                                           Ron

Regards,
Jeff

Cheng

+1

Dan

Hi Andrew,

Best regards,
Moonlight Thoughts

Thanks

Andrew

spring mailing list

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Sep 2019 02:28:09 +0200

Hi Ron,

While sitting and watching this very educational thread to enhance anyone
linguistic skills why don't you just call your architecture as either SRc6
or SRs6 and move on ?

Legend:

c - compressed
s - squeezed or shrank

Best,
Robert.

PS. That is not to say that I suddenly think the proposal is overall sound
:)

---

From: Ron Bonica <[email-masked]>
Date: Sat, 28 Sep 2019 01:01:33 +0000

Hi Daniel,

The PSSI is immutable. It cannot be swapped. Also, service instructions augment, but to not define a path.

So, what exactly do we mean by that? Assume that PSSI 100 resolves as follows:

- To Service 1 at SE 1
- To Service 2 at SE 2
- To Service 3 at SE 3

Now assume that PSSI 100 proceeds the CRH in the following SR Paths:

1) PE1-SE1-PE2
2) PE1-SE2-PE2
3) PE1- SE1-SE2-SE3-PE2
4) PE1-SE3-SE2-SE1-PE2

In the first case, only Service 1 is rendered. In the second case, only Service 2 is rendered. In the third case, all three services are rendered. And in the fourth case, all three services are rendered, but in the reverse order.

PSSI 100 can also be used in the following SR paths:

-  PE3- SE1-SE2-SE3-PE5
-  PE1-SE3-SE2-SE1-SE5-PE2

In the first case, the PE's are different. In the second case SE5 is added. If SE5 is a core router, may skip over the PSSI.

                                                                                                               Ron

-----Original Message-----
From: Bernier, Daniel <[email-masked]> 
Sent: Thursday, September 26, 2019 8:29 AM
To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Ron,

Cheers,

Dan

Daniel,

                                                                                                                 Ron

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Bernier, Daniel
Sent: Wednesday, September 25, 2019 4:07 PM
To: Joel M. Halpern <[email-masked]>
Cc: SPRING WG List <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Ah but Joel,

Yours,
Joel

On 9/25/2019 3:41 PM, Bernier, Daniel wrote:
> <[email-masked]>, wrote:
>
>     I agree.
>
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8402*sectio
> n-3.1.3__;Iw!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKT
> ovGi8h8S5bZxBkXNLjq$
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/Spri
> S5bZxDonQAID$

---

From: Ron Bonica <[email-masked]>
Date: Sun, 29 Sep 2019 14:25:53 +0000

Robert,

I was thinking about SR-compressed-6. SRc6 is a nice abbreviation for that.

If the WG agrees, I will update the drafts.

                        Ron

From: Robert Raszuk <[email-masked]>
Sent: Friday, September 27, 2019 8:28 PM
To: Ron Bonica <[email-masked]>
Cc: Zafar Ali (zali) <[email-masked]>; EXT - [email-masked] <[email-masked]>; Jeff Tantsura <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; Stewart Bryant <[email-masked]>; SPRING WG List <[email-masked]>; SING Team <[email-masked]>
Subject: Re: [spring] SR-MPLS over IPv6？

Hi Ron,

While sitting and watching this very educational thread to enhance anyone linguistic skills why don't you just call your architecture as either SRc6 or SRs6 and move on ?

Legend:

c - compressed
s - squeezed or shrank

Best,
Robert.

PS. That is not to say that I suddenly think the proposal is overall sound :)

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 29 Sep 2019 16:56:27 +0200

Hi Ron,

You may also consider *SR-mapped-6* (SRm6) as it even better reflects the
spirit of the proposal.

Thx,
R.

On Sun, Sep 29, 2019 at 4:26 PM Ron Bonica <[email-masked]> wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, September 27, 2019 8:28 PM
> *Cc:* Zafar Ali (zali) <[email-masked]>; EXT - [email-masked] <
> [email-masked]>; Jeff Tantsura <[email-masked]>; Chengli
> (Cheng Li) <[email-masked]>; Stewart Bryant <
> [email-masked]>; SPRING WG List <[email-masked]>; SING Team <
> *Subject:* Re: [spring] SR-MPLS over IPv6？
>
>
>
> Hi Ron,
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 30 Sep 2019 08:11:04 +0000

Robert,

I like SR-mapped-6 (SRm6) even better. When spoken “S-R-C-6” sounds too much like “S-R-V-6”. The two will be confused. SRm6 won’t have that problem.

                                                                            Ron

Sent: Sunday, September 29, 2019 10:56 AM

Hi Ron,

You may also consider SR-mapped-6 (SRm6) as it even better reflects the spirit of the proposal.

Thx,
R.

On Sun, Sep 29, 2019 at 4:26 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                        Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 27, 2019 8:28 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; EXT - [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; SING Team <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] SR-MPLS over IPv6？

Hi Ron,

Legend:

c - compressed
s - squeezed or shrank

Best,
Robert.