date:20190926

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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
> 
>
>
>
> 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 <
> jefftant.i...@gmail.com>
> *Cc:* SING Team  >; EXT - daniel.bern...@bell.ca <
> 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

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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) 
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:

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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) 
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) mailto:chengl...@huawei.com>>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: SING Team

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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) 
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) 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>>; 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)

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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 
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) 
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) 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>>; 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>>; 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

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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" > 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) 

*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) 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>>;
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>>;
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

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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" > 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


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

Re: [spring] SR-MPLS over IPv6？

2019-09-26 Thread 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"  > 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc8402*section-3.1.3__;Iw!8WoA6RjC81c!RWveUAxArVXDm5sHbHNujZusNPIClQSSBL5x2iGIxptKTovGi8h8S5bZxBkXNLjq$
>
>

Re: [spring] SR-MPLS over IPv6？

Re: [spring] SR-MPLS over IPv6？

Re: [spring] SR-MPLS over IPv6？

Re: [spring] SR-MPLS over IPv6？

Re: [spring] SR-MPLS over IPv6？

Re: [spring] SR-MPLS over IPv6？

Re: [spring] SR-MPLS over IPv6？

Re: [spring] SR-MPLS over IPv6？

8 matches

Site Navigation

Mail list logo

Footer information