Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

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


From: Robert Raszuk 
Sent: Sunday, September 29, 2019 10:56 AM
To: Ron Bonica 
Cc: Zafar Ali (zali) ; EXT - daniel.bern...@bell.ca 
; Jeff Tantsura ; Chengli 
(Cheng Li) ; Stewart Bryant ; 
SPRING WG List ; SING Team 
Subject: Re: [spring] SR-MPLS over IPv6？

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 
mailto:rbon...@juniper.net>> wrote:
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 mailto:rob...@raszuk.net>>
Sent: Friday, September 27, 2019 8:28 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: Zafar Ali (zali) mailto:z...@cisco.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Chengli (Cheng Li) 
mailto:chengl...@huawei.com>>; Stewart Bryant 
mailto:stewart.bry...@gmail.com>>; SPRING WG List 
mailto:spr...@ietf..org>>; SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>
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 :)



Juniper Business Use Only


Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SR-MPLS over IPv6？

[Robert Raszuk]

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  wrote:

> 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 
> *Sent:* Friday, September 27, 2019 8:28 PM
> *To:* Ron Bonica 
> *Cc:* Zafar Ali (zali) ; EXT - daniel.bern...@bell.ca <
> daniel.bern...@bell.ca>; Jeff Tantsura ; Chengli
> (Cheng Li) ; Stewart Bryant <
> stewart.bry...@gmail.com>; SPRING WG List ; SING Team <
> s.i.n.g.team.0...@gmail.com>
> *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
> :)
>
>
>
>
>
> Juniper Business Use Only
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

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 
Sent: Friday, September 27, 2019 8:28 PM
To: Ron Bonica 
Cc: Zafar Ali (zali) ; EXT - daniel.bern...@bell.ca 
; Jeff Tantsura ; Chengli 
(Cheng Li) ; Stewart Bryant ; 
SPRING WG List ; SING Team 
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 :)



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

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

Juniper Business Use Only

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

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

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


 Ron


Juniper Business Use Only

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

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 
Sent: Wednesday, September 25, 2019 3:50 PM
To: Bernier, Daniel
Cc: SPRING WG List
Subject: [EXT]Re: [spring] SR-MPLS over IPv6？

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
>
> On 2019-09-25, 8:43 AM, "Jeff Tantsura"  <mailto:jefftant.i...@gmail.com>> wrote:
>
> 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 
> , 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
>
> On 24/09/2019 05:01, Ron Bonica wrote:
>
> Cheng,
>
> 

Re: [spring] SR-MPLS over IPv6？

[Robert Raszuk]

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
:)
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] SR-MPLS over IPv6？

[Mark Smith]

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),  wrote:

> 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  on behalf of "Bernier, Daniel" <
> daniel.bern...@bell.ca>
> *Date: *Wednesday, September 25, 2019 at 3:41 PM
> *To: *Jeff Tantsura , Ron Bonica  40juniper@dmarc.ietf.org>, "Chengli (Cheng Li)" ,
> Stewart Bryant 
> *Cc: *SPRING WG List , SING Team <
> s.i.n.g.team.0...@gmail.com>
> *Subject: *Re: [spring] SR-MPLS over IPv6？
>
>
>
> 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"  wrote:
>
>
>
> 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 ,
> 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
>
> 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.
>
>
>
> Something like SR-extensible-6 or SR-compressed-6 might work.
>
>
>
>Ron
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Chengli (Cheng Li)  
> *Sent:* Monday, September 23, 2019 10:14 PM
> *To:* Ron Bonica  ; Jeff
> Tantsura  
> *Cc:* SING Team 
> ; EXT - daniel.bern...@bell.ca
>  ; SPRING WG List
>  
> *Subject:* RE: [spring] SR-MPLS over IPv6？
>
>
>
> 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
> <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?
>
>
&

Re: [spring] SR-MPLS over IPv6？

[Zafar Ali (zali)]

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 
Date: Thursday, September 26, 2019 at 2:58 PM
To: "Zafar Ali (zali)" , "EXT - daniel.bern...@bell.ca" 
, Jeff Tantsura , "Chengli 
(Cheng Li)" , Stewart Bryant 
Cc: SPRING WG List , SING Team 
Subject: RE: [spring] SR-MPLS over IPv6？

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) 
Sent: Thursday, September 26, 2019 12:17 PM
To: EXT - daniel.bern...@bell.ca ; Jeff Tantsura 
; Ron Bonica ; Chengli (Cheng Li) 
; Stewart Bryant 
Cc: SPRING WG List ; SING Team ; 
Zafar Ali (zali) 
Subject: Re: [spring] SR-MPLS over IPv6？

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 mailto:spring-boun...@ietf.org>> on 
behalf of "Bernier, Daniel" 
mailto:daniel.bern...@bell.ca>>
Date: Wednesday, September 25, 2019 at 3:41 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>,
 "Chengli (Cheng Li)" mailto:chengl...@huawei.com>>, 
Stewart Bryant mailto:stewart.bry...@gmail.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>, SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>
Subject: Re: [spring] SR-MPLS over IPv6？

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" 
mailto:jefftant.i...@gmail.com>> wrote:

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 
mailto:stewart.bry...@gmail.com>>, 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
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.

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

   Ron



Juniper Business Use Only
From: Chengli (Cheng Li) <mailto:chengl...@huawei.com>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <mailto:rbon...@juniper.net>; Jeff Tantsura 
<mailto:jefftant.i...@gmail.com>
Cc: SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
<mailto:daniel.bern...@bell.ca>; SPRING WG List 
<mailto:spring@ietf.org>
Subject: RE: [spring] SR-MPLS over IPv6？

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

Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

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) 
Sent: Thursday, September 26, 2019 12:17 PM
To: EXT - daniel.bern...@bell.ca ; Jeff Tantsura 
; Ron Bonica ; Chengli (Cheng Li) 
; Stewart Bryant 
Cc: SPRING WG List ; SING Team ; 
Zafar Ali (zali) 
Subject: Re: [spring] SR-MPLS over IPv6？

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 mailto:spring-boun...@ietf.org>> on 
behalf of "Bernier, Daniel" 
mailto:daniel.bern...@bell.ca>>
Date: Wednesday, September 25, 2019 at 3:41 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>,
 "Chengli (Cheng Li)" mailto:chengl...@huawei.com>>, 
Stewart Bryant mailto:stewart.bry...@gmail.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>, SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>
Subject: Re: [spring] SR-MPLS over IPv6？

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" 
mailto:jefftant.i...@gmail.com>> wrote:

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 
mailto:stewart.bry...@gmail.com>>, 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
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.

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

   Ron



Juniper Business Use Only
From: Chengli (Cheng Li) <mailto:chengl...@huawei.com>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <mailto:rbon...@juniper.net>; Jeff Tantsura 
<mailto:jefftant.i...@gmail.com>
Cc: SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
<mailto:daniel.bern...@bell.ca>; SPRING WG List 
<mailto:spring@ietf.org>
Subject: RE: [spring] SR-MPLS over IPv6？

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<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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM

Re: [spring] SR-MPLS over IPv6？

[Zafar Ali (zali)]

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  on behalf of "Bernier, Daniel" 

Date: Wednesday, September 25, 2019 at 3:41 PM
To: Jeff Tantsura , Ron Bonica 
, "Chengli (Cheng Li)" 
, Stewart Bryant 
Cc: SPRING WG List , SING Team 
Subject: Re: [spring] SR-MPLS over IPv6？

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" 
mailto:jefftant.i...@gmail.com>> wrote:

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

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

   Ron



Juniper Business Use Only
From: Chengli (Cheng Li) <mailto:chengl...@huawei.com>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <mailto:rbon...@juniper.net>; Jeff Tantsura 
<mailto:jefftant.i...@gmail.com>
Cc: SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
<mailto:daniel.bern...@bell.ca>; SPRING WG List 
<mailto:spring@ietf.org>
Subject: RE: [spring] SR-MPLS over IPv6？

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<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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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
  

Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

Exactly like a binding SID

Ron
Sent from my phone


On Sep 26, 2019, at 10:07 AM, Stewart Bryant 
mailto:stewart.bry...@gmail.com>> wrote:



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



Juniper Business Use Only
From: Bernier, Daniel <mailto:daniel.bern...@bell.ca>
Sent: Wednesday, September 25, 2019 3:41 PM
To: Jeff Tantsura <mailto:jefftant.i...@gmail.com>; 
Ron Bonica <mailto:rbon...@juniper.net>; Chengli (Cheng 
Li) <mailto:chengl...@huawei.com>; Stewart Bryant 
<mailto:stewart.bry...@gmail.com>
Cc: SPRING WG List <mailto:spring@ietf.org>; SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>
Subject: RE: [spring] SR-MPLS over IPv6？

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" 
mailto:jefftant.i...@gmail.com>> wrote:

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 
mailto:stewart.bry...@gmail.com>>, 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
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.

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

   Ron



Juniper Business Use Only
From: Chengli (Cheng Li) <mailto:chengl...@huawei.com>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <mailto:rbon...@juniper.net>; Jeff Tantsura 
<mailto:jefftant.i...@gmail.com>
Cc: SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
<mailto:daniel.bern...@bell.ca>; SPRING WG List 
<mailto:spring@ietf.org>
Subject: RE: [spring] SR-MPLS over IPv6？

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<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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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) mailto:chengl...@huawei.com>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
Subject: RE: [spring] A note on CRH and on going testing

Hi Ron,

Good to hear that. Looking forward to seeing it in the nex

Re: [spring] SR-MPLS over IPv6？

[Stewart Bryant]

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


Juniper Business Use Only

*From:*Bernier, Daniel 
*Sent:* Wednesday, September 25, 2019 3:41 PM
*To:* Jeff Tantsura ; Ron Bonica 
; Chengli (Cheng Li) ; 
Stewart Bryant 
*Cc:* SPRING WG List ; SING Team 


*Subject:* RE: [spring] SR-MPLS over IPv6？

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" <mailto:jefftant.i...@gmail.com>> wrote:


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 
mailto:stewart.bry...@gmail.com>>, 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

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.

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

Ron

Juniper Business Use Only

*From:*Chengli (Cheng Li) 
<mailto:chengl...@huawei.com>
*Sent:* Monday, September 23, 2019 10:14 PM
*To:* Ron Bonica 
<mailto:rbon...@juniper.net>; Jeff Tantsura
 <mailto:jefftant.i...@gmail.com>
*Cc:* SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT -
daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
 <mailto:daniel.bern...@bell.ca>;
    SPRING WG List  <mailto:spring@ietf.org>
*Subject:* RE: [spring] SR-MPLS over IPv6？

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

<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:rbon...@juniper.net]
*Sent:* Monday, September 23, 2019 10:45 PM
*To:* Chengli (Cheng Li) mailto:chengl...@huawei.com>>; Jeff Tantsura
mailto:jefftant.i...@gmail.com>>
*Cc:* SING Team mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
mailto:daniel.bern...@bell.ca>>;
SPRING WG List mailto:spring@ietf.org>>
*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) mailto:chengl...@huawei.com>>
*Sent:* Sunday, September 22, 2019 12:01 AM
*To:* Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura
mailto:jefftant.i...@gmail.com>>
*Cc:* SING Team mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
mailto:daniel.bern...@bell.ca>>;
SPRING WG List mailto:spring@ietf.org>>
*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.

Re: [spring] SR-MPLS over IPv6？

[Stewart Bryant]

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


- Stewart

On 25/09/2019 20:50, Joel M. Halpern wrote:
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

On 2019-09-25, 8:43 AM, "Jeff Tantsura" <mailto:jefftant.i...@gmail.com>> wrote:


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

    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.

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

Ron

    Juniper Business Use Only

    *From:* Chengli (Cheng Li) 
    <mailto:chengl...@huawei.com>
    *Sent:* Monday, September 23, 2019 10:14 PM
    *To:* Ron Bonica 
    <mailto:rbon...@juniper.net>; Jeff Tantsura
     <mailto:jefftant.i...@gmail.com>
    *Cc:* SING Team 
    <mailto:s.i.n.g.team.0...@gmail.com>; EXT -
    daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
     <mailto:daniel.bern...@bell.ca>; SPRING
    WG List  <mailto:spring@ietf.org>
    *Subject:* RE: [spring] SR-MPLS over IPv6？

    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
<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:rbon...@juniper.net]
    *Sent:* Monday, September 23, 2019 10:45 PM
    *To:* Chengli (Cheng Li) mailto:chengl...@huawei.com>>; Jeff Tantsura
    mailto:jefftant.i...@gmail.com>>
    *Cc:* SING Team mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
    daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
    mailto:daniel.bern...@bell.ca>>; SPRING
    WG List mailto:spring@ietf.org>>
    *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) mailto:chengl...@huawei.com>>
    *Sent:* Sunday, September 22, 2019 12:01 AM
    *To:* Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura
    mailto:jefftant.i...@gmail.com>>
    *Cc:* SING Team mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
    daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
    mailto:daniel.bern...@bell.ca>>; SPRING
    WG List mailto:spring@ietf.org>>
    *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.

  

Re: [spring] SR-MPLS over IPv6？

[Bernier, Daniel]

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

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


 Ron


Juniper Business Use Only

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

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 
Sent: Wednesday, September 25, 2019 3:50 PM
To: Bernier, Daniel
Cc: SPRING WG List
Subject: [EXT]Re: [spring] SR-MPLS over IPv6？

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
>
> On 2019-09-25, 8:43 AM, "Jeff Tantsura"  <mailto:jefftant.i...@gmail.com>> wrote:
>
> 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
> , 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
>
> 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.
>
> Something like SR-extensible-6 or SR-compressed-6 might work.
>
>
> Ron
>
> Juniper Business Use Only
>
> *From:* Chengli (Cheng Li) 
> <mailto:chengl...@huawei.com>
> *Sent:* Monday, September 23, 2019 10:14 PM
> *To:* Ron Bonica 
> <mailto:rbon...@juniper.net>; Jeff Tantsura
>  <mailto:jefftant.i...@gmail.com>
> *Cc:* SING Team 
> <mailto:s.i.n.g.team.0...@gmail.com>; EXT -
> daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
>  <mailto:daniel.bern...@bell.ca>; SPRING
> WG List  <mailto:spring@ietf.org>
> *Subject:* RE: [spring] SR-MPLS over IPv6？
>
> 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://url

Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

Daniel,

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


 Ron


Juniper Business Use Only

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

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 
Sent: Wednesday, September 25, 2019 3:50 PM
To: Bernier, Daniel
Cc: SPRING WG List
Subject: [EXT]Re: [spring] SR-MPLS over IPv6？

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
>
> On 2019-09-25, 8:43 AM, "Jeff Tantsura"  <mailto:jefftant.i...@gmail.com>> wrote:
>
> 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 
> , 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
>
> 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.
>
> Something like SR-extensible-6 or SR-compressed-6 might work.
>
> 
> Ron
>
> Juniper Business Use Only
>
> *From:* Chengli (Cheng Li) 
> <mailto:chengl...@huawei.com>
> *Sent:* Monday, September 23, 2019 10:14 PM
> *To:* Ron Bonica 
> <mailto:rbon...@juniper.net>; Jeff Tantsura
>  <mailto:jefftant.i...@gmail.com>
> *Cc:* SING Team 
> <mailto:s.i.n.g.team.0...@gmail.com>; EXT -
> daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
>  <mailto:daniel.bern...@bell.ca>; SPRING
> WG List  <mailto:spring@ietf.org>
> *Subject:* RE: [spring] SR-MPLS over IPv6？
>
> 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://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$>
>
> 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:rbon...@juniper.net]
> *Sent:* Monday, September 23, 2019 10:45 PM
> *To:* Chengli (Cheng Li)  <mailto:chengl...@huawei.com>>; Jeff Tantsura
> mailto:jefftant.i...@gmail.com>>
> *Cc:* SING Team  <mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
> daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
> mailto:daniel.bern...@bell.ca>>; SPRING
> WG List mailto:spring@ietf.org>>
>

Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

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 
Sent: Wednesday, September 25, 2019 3:41 PM
To: Jeff Tantsura ; Ron Bonica ; 
Chengli (Cheng Li) ; Stewart Bryant 

Cc: SPRING WG List ; SING Team 
Subject: RE: [spring] SR-MPLS over IPv6？

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" 
mailto:jefftant.i...@gmail.com>> wrote:

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 
mailto:stewart.bry...@gmail.com>>, 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
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.

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

   Ron



Juniper Business Use Only
From: Chengli (Cheng Li) <mailto:chengl...@huawei.com>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <mailto:rbon...@juniper.net>; Jeff Tantsura 
<mailto:jefftant.i...@gmail.com>
Cc: SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
<mailto:daniel.bern...@bell.ca>; SPRING WG List 
<mailto:spring@ietf.org>
Subject: RE: [spring] SR-MPLS over IPv6？

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<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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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) mailto:chengl...@huawei.com>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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
Em

Re: [spring] SR-MPLS over IPv6？

[Bernier, Daniel]

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 
Sent: Wednesday, September 25, 2019 3:50 PM
To: Bernier, Daniel
Cc: SPRING WG List
Subject: [EXT]Re: [spring] SR-MPLS over IPv6？

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
>
> On 2019-09-25, 8:43 AM, "Jeff Tantsura"  <mailto:jefftant.i...@gmail.com>> wrote:
>
> 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
> , 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
>
> 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.
>
> Something like SR-extensible-6 or SR-compressed-6 might work.
>
> Ron
>
> Juniper Business Use Only
>
> *From:* Chengli (Cheng Li) 
> <mailto:chengl...@huawei.com>
> *Sent:* Monday, September 23, 2019 10:14 PM
> *To:* Ron Bonica 
> <mailto:rbon...@juniper.net>; Jeff Tantsura
>  <mailto:jefftant.i...@gmail.com>
> *Cc:* SING Team 
> <mailto:s.i.n.g.team.0...@gmail.com>; EXT -
> daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
>  <mailto:daniel.bern...@bell.ca>; SPRING
> WG List  <mailto:spring@ietf.org>
> *Subject:* RE: [spring] SR-MPLS over IPv6？
>
> 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
> 
> <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:rbon...@juniper.net]
> *Sent:* Monday, September 23, 2019 10:45 PM
> *To:* Chengli (Cheng Li)  <mailto:chengl...@huawei.com>>; Jeff Tantsura
> mailto:jefftant.i...@gmail.com>>
> *Cc:* SING Team  <mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
> daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
> mailto:daniel.bern...@bell.ca>>; SPRING
> WG List mailto:spring@ietf.org>>
> *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.
&

Re: [spring] SR-MPLS over IPv6？

[Joel M. Halpern]

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

On 2019-09-25, 8:43 AM, "Jeff Tantsura" <mailto:jefftant.i...@gmail.com>> wrote:


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

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.

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

    Ron

Juniper Business Use Only

*From:* Chengli (Cheng Li) 
<mailto:chengl...@huawei.com>
*Sent:* Monday, September 23, 2019 10:14 PM
*To:* Ron Bonica 
<mailto:rbon...@juniper.net>; Jeff Tantsura
 <mailto:jefftant.i...@gmail.com>
*Cc:* SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT -
daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
 <mailto:daniel.bern...@bell.ca>; SPRING
    WG List  <mailto:spring@ietf.org>
*Subject:* RE: [spring] SR-MPLS over IPv6？

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

<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:rbon...@juniper.net]
*Sent:* Monday, September 23, 2019 10:45 PM
*To:* Chengli (Cheng Li) mailto:chengl...@huawei.com>>; Jeff Tantsura
mailto:jefftant.i...@gmail.com>>
*Cc:* SING Team mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
mailto:daniel.bern...@bell.ca>>; SPRING
WG List mailto:spring@ietf.org>>
*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) mailto:chengl...@huawei.com>>
*Sent:* Sunday, September 22, 2019 12:01 AM
*To:* Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura
mailto:jefftant.i...@gmail.com>>
*Cc:* SING Team mailto:s.i.n.g.team.0...@gmail.com>>; EXT -
daniel.bern...@bell.ca <mailto:daniel.bern...@bell.ca>
mailto:daniel.bern...@bell.ca>>; SPRING
WG List mailto:spring@ietf.org>>
*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 inte

Re: [spring] SR-MPLS over IPv6？

[Bernier, Daniel]

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" 
mailto:jefftant.i...@gmail.com>> wrote:

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

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

   Ron



Juniper Business Use Only
From: Chengli (Cheng Li) <mailto:chengl...@huawei.com>
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica <mailto:rbon...@juniper.net>; Jeff Tantsura 
<mailto:jefftant.i...@gmail.com>
Cc: SING Team 
<mailto:s.i.n.g.team.0...@gmail.com>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
<mailto:daniel.bern...@bell.ca>; SPRING WG List 
<mailto:spring@ietf.org>
Subject: RE: [spring] SR-MPLS over IPv6？

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<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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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) mailto:chengl...@huawei.com>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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: chengl...@huawei.com<mailto:chengl...@huawei.com>
From: Ron Bonicamailto:rbon...@juniper.net>>
To: Jeff 
Tantsuramailto:jefftant.i...@gmail.com>>;Chengli 
(Cheng Li)mailto:chengl...@huawei.com>>
Cc: SING 
Teammailto:s.i.n.g.team.0...@gmail.com>>;EXT - 
daniel.berniermailto:daniel.bern...@bell.ca>>;SPRING WG 
Listmailto:spring@ietf.org>>
Subject: RE: [spring] A note on CRH and on going testing
Time: 2019-09-22 04:37:17

Jeff,

After an o

Re: [spring] SR-MPLS over IPv6？

[Jeff Tantsura]

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 , 
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
> 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.
> >
> > Something like SR-extensible-6 or SR-compressed-6 might work.
> >
> >    Ron
> >
> >
> > Juniper Business Use Only
> > From: Chengli (Cheng Li) 
> > Sent: Monday, September 23, 2019 10:14 PM
> > To: Ron Bonica ; Jeff Tantsura 
> > 
> > Cc: SING Team ; EXT - daniel.bern...@bell.ca 
> > ; SPRING WG List 
> > Subject: RE: [spring] SR-MPLS over IPv6？
> >
> > 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:rbon...@juniper.net]
> > Sent: Monday, September 23, 2019 10:45 PM
> > To: Chengli (Cheng Li) ; Jeff Tantsura 
> > 
> > Cc: SING Team ; EXT - daniel.bern...@bell.ca 
> > ; SPRING WG List 
> > 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) 
> > Sent: Sunday, September 22, 2019 12:01 AM
> > To: Ron Bonica ; Jeff Tantsura 
> > 
> > Cc: SING Team ; EXT - daniel.bern...@bell.ca 
> > ; SPRING WG List 
> > 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: chengl...@huawei.com
> > From: Ron Bonica
> > To: Jeff Tantsura;Chengli (Cheng 
> > Li)
> > Cc: SING Team;EXT - 
> > daniel.bernier;SPRING WG List
> > 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 
> > Sent: Saturday, September 21, 2019 4:32 PM
> > To: Chengli (Cheng Li) ; Ron Bonica 
> > 
&

Re: [spring] SR-MPLS over IPv6？

[Stewart Bryant]

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.


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

Ron

Juniper Business Use Only

*From:*Chengli (Cheng Li) 
*Sent:* Monday, September 23, 2019 10:14 PM
*To:* Ron Bonica ; Jeff Tantsura 

*Cc:* SING Team ; EXT - 
daniel.bern...@bell.ca ; SPRING WG List 


*Subject:* RE: [spring] SR-MPLS over IPv6？

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 
<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:rbon...@juniper.net]
*Sent:* Monday, September 23, 2019 10:45 PM
*To:* Chengli (Cheng Li) <mailto:chengl...@huawei.com>>; Jeff Tantsura <mailto:jefftant.i...@gmail.com>>
*Cc:* SING Team <mailto:s.i.n.g.team.0...@gmail.com>>; EXT - daniel.bern...@bell.ca 
<mailto:daniel.bern...@bell.ca> <mailto:daniel.bern...@bell.ca>>; SPRING WG List <mailto:spring@ietf.org>>

*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) <mailto:chengl...@huawei.com>>

*Sent:* Sunday, September 22, 2019 12:01 AM
*To:* Ron Bonica mailto:rbon...@juniper.net>>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>
*Cc:* SING Team <mailto:s.i.n.g.team.0...@gmail.com>>; EXT - daniel.bern...@bell.ca 
<mailto:daniel.bern...@bell.ca> <mailto:daniel.bern...@bell.ca>>; SPRING WG List <mailto:spring@ietf.org>>

*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: chengl...@huawei.com <mailto:chengl...@huawei.com>

*From: *Ron Bonicamailto:rbon...@juniper.net>>

*To: *Jeff Tantsura<mailto:jefftant.i...@gmail.com>>;Chengli (Cheng 
Li)mailto:chengl...@huawei.com>>


*Cc: *SING Team<mailto:s.i.n.g.team.0...@gmail.com>>;EXT - 
daniel.bernier<mailto:daniel.bern...@bell.ca>>;SPRING WG List<mailto:spring@ietf.org>>


*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 <mailto:jefftant.i...@gmail.com>>

*Sent:* Saturday, September 21, 2019 4:32 PM
*To:* Chengli (Cheng Li) <mailto:chengl...@huawei.com>>; Ron Bonica <mailto:rbon...@juniper.net>>
*Cc:* SING Team <mailto:s.i.n.g.team.0...@gmail.com>>; EXT - daniel.bern...@bell.ca 
<mailto:daniel.bern...@bell.ca> <mailto:daniel.bern...@bell.ca>>; SPRING WG List <mailto:spring@ietf.org>>

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

Hi Ron,

Thanks for your comments, exactly, BSID MPLS lab

Re: [spring] SR-MPLS over IPv6？

[Ron Bonica]

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) 
Sent: Monday, September 23, 2019 10:14 PM
To: Ron Bonica ; Jeff Tantsura 
Cc: SING Team ; EXT - daniel.bern...@bell.ca 
; SPRING WG List 
Subject: RE: [spring] SR-MPLS over IPv6？

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<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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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) mailto:chengl...@huawei.com>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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: chengl...@huawei.com<mailto:chengl...@huawei.com>
From: Ron Bonicamailto:rbon...@juniper.net>>
To: Jeff 
Tantsuramailto:jefftant.i...@gmail.com>>;Chengli 
(Cheng Li)mailto:chengl...@huawei.com>>
Cc: SING 
Teammailto:s.i.n.g.team.0...@gmail.com>>;EXT - 
daniel.berniermailto:daniel.bern...@bell.ca>>;SPRING WG 
Listmailto:spring@ietf.org>>
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 mailto:jefftant.i...@gmail.com>>
Sent: Saturday, September 21, 2019 4:32 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; Ron 
Bonica mailto:rbon...@juniper.net>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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 
mailto:rbon...@juniper.net>>, 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 sa

Re: [spring] SR-MPLS over IPv6？

[Chengli (Cheng Li)]

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:rbon...@juniper.net]
Sent: Monday, September 23, 2019 10:45 PM
To: Chengli (Cheng Li) ; Jeff Tantsura 

Cc: SING Team ; EXT - daniel.bern...@bell.ca 
; SPRING WG List 
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) mailto:chengl...@huawei.com>>
Sent: Sunday, September 22, 2019 12:01 AM
To: Ron Bonica mailto:rbon...@juniper.net>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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: chengl...@huawei.com
From: Ron Bonicamailto:rbon...@juniper.net>>
To: Jeff 
Tantsuramailto:jefftant.i...@gmail.com>>;Chengli 
(Cheng Li)mailto:chengl...@huawei.com>>
Cc: SING 
Teammailto:s.i.n.g.team.0...@gmail.com>>;EXT - 
daniel.berniermailto:daniel.bern...@bell.ca>>;SPRING WG 
Listmailto:spring@ietf.org>>
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 mailto:jefftant.i...@gmail.com>>
Sent: Saturday, September 21, 2019 4:32 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>; Ron 
Bonica mailto:rbon...@juniper.net>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
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 
mailto:rbon...@juniper.net>>, 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 mailto:spring-boun...@ietf.org>> On 
Behalf Of Jeff Tantsura
Sent: Thursday, September 19, 2019 10:53 PM
To: Chengli (Cheng Li) mailto:chengl...@huawei.com>>
Cc: SING Team 
mailto:s.i.n.g.team.0...@gmail.com>>; EXT - 
daniel.bern...@bell.ca 
mailto:daniel.bern...@bell.ca>>; SPRING WG List 
mailto:spring@ietf.org>>
Subject: Re: [spring] A note on CRH and on going testing

There’s number of solutions on the market that extensively use BSID for 
multi-domain as