Re: [spring] Fwd: IETF WG state changed for draft-ietf-spring-srv6-srh-compression

[Bernier, Daniel]

Hi,


I support this document, having an already working implementation of it in 
production 
https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status-15#section-2.11


Regards,


Daniel Bernier





From: spring  on behalf of Joel Halpern 

Sent: Monday, January 22, 2024 9:28 AM
To: SPRING WG List
Subject: [spring] Fwd: IETF WG state changed for 
draft-ietf-spring-srv6-srh-compression


(One of the other chairs pointed out that this had not gone to the list.  So 
forwarding the announcement.)

This tarts the WG last call on the above document.

Thank you,

Joel


 Forwarded Message 
Subject:IETF WG state changed for draft-ietf-spring-srv6-srh-compression
Resent-Date:Sun, 21 Jan 2024 11:25:02 -0800 (PST)
Resent-From:alias-boun...@ietf.org
Resent-To:  bruno.decra...@orange.com, 
aretana.i...@gmail.com, 
j...@joelhalpern.com, 
pengshup...@huawei.com
Date:   Sun, 21 Jan 2024 11:25:02 -0800
From:   IETF Secretariat 

To: 
draft-ietf-spring-srv6-srh-compress...@ietf.org,
 spring-cha...@ietf.org



The IETF WG state of draft-ietf-spring-srv6-srh-compression has been changed
to "In WG Last Call" from "WG Document" by Joel Halpern:

https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/

Comment:
This starts the WG last call for this document. Please comment with support
or opposition, and explanation of your perspective. Silence is not consent,
and just "support" or "oppose" is not helpful. This call will run through
the end of Feb 4, 2024. Yours, Joel Halpern - responsible Spring co-chair

PS: I would appreciate a document shepherd from the WG for the bnext step. 
Email me if you are willing.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

[Bernier, Daniel]

Hi

Support the adoption to WG

Daniel Bernier

On 2023-05-16, 10:04 AM, "spring on behalf of IETF Secretariat" 
mailto:spring-boun...@ietf.org> on behalf of 
ietf-secretariat-re...@ietf.org > wrote:




The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state
Candidate for WG Adoption (entered by Joel Halpern)


The document is available at
https://datatracker.ietf.org/doc/draft-schmutzer-spring-cs-sr-policy/ 



Comment:
This starts a two week adoption call for the subject draft. Please speak up
if you support or object to WG adoption. Two notes: 1) WG adoption is the
start of the process. The basic question is whether you agree that the
subject is worth the working group time to work on, and whether this
represents a good starting point for the work. 2) Please include explanation
for your view. Yes or no are not very helpful answers, as this is not a vote
but an evaluation of support and concerns. Thank you, Joel (for the WG Chairs)


We expect to close this call at the end of May, 2023.


___
spring mailing list
spring@ietf.org 
https://www.ietf.org/mailman/listinfo/spring 

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





___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Bernier, Daniel]

Hi,

After re-reading the draft I strongly support its adoption.


  1.  Following the Design Team work stream, CSID proves conformant and optimal.
  2.  It allows for the flexibility of selecting the SRv6 data plane flavor 
(compressed or not) without changes to the architecture.
  3.  Has proven quite easy to implement with our existing HW platforms (in a 
matter of hours for some ASICs)
  4.  As my colleague Dan Voyer pointed out, we successfully deployed in 
production with live traffic.  And in a multi-vendor environment.

Thanks,

Dan B

From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: "spring-cha...@ietf.org" 
Subject: [EXT][spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


1.   The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.

2.   The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.

3.   All open discussion points raised on our mailing list MUST be 
addressed BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.

4.   If this document is adopted by the working group, the chairs specify 
as part of the adoption call that the following text describing an open issue 
be added to the document in the above-described open issues section:

· "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[Bernier, Daniel]

Support adoption of both documents

Dan B

From: spring  on behalf of "bruno.decra...@orange.com" 

Date: Tuesday, September 7, 2021 at 9:12 AM
To: "spring@ietf.org" 
Subject: [EXT][spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still 
individual documents.
We believe it's now time for the WG to consider taking ownership of those two 
documents.
Note that, especially for those two documents, WG adoption does not necessarily 
mean RFC publication in particular if it turns out that the benefit of long 
term archive would not justify the WG and IESG effort to finalize those two 
documents.


This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis


After review of the document(s) please indicate support (or not) for WG 
adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this 
is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. 
This gives the chairs an indication of the energy level of people in the 
working group willing to work on the document.

Thanks!

Jim, Bruno & Joel


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Progressing Standardizing SR over IPv6 compression

[Bernier, Daniel]

Hi, 

Similar to my comment on the chat during SPRING last Monday. The mailing list 
has been flooded of opinions, exchanges, technical arguments on all variations, 
to the extent that it triggered the WG to initiate that DT effort to help get 
better clarity.
I really do think that it would be counterproductive to go back to the list, 
restart another lengthy technical discussion thread and discard the outcome of 
what the DT has produced.
 
This discussion has slowed progress on various aspects of the industry (from 
ASIC SDKs, to large incumbents and new vendors support)  and in turn slowed 
down our ability to deploy. Nonetheless, the community is moving forward with 
efforts like SONIC 
on normalizing CSID and SRH within the SAI for broad homogeneous adoption. 

So, to the question "Should the working group standardize one data plane 
behavior for compressing SRv6 information?"

I would say a Yes and please follow the outcome of the DT work

Cheers, 

Dan B

On 2021-08-04, 2:52 PM, "spring on behalf of Joel M. Halpern" 
 wrote:

The SPRING Working Group Chairs thank the design team for their efforts 
on the requirements and analysis drafts.  The question of how the 
working group wants to progress that part of the work will be the topic 
for a separate email a bit later.

Right now, we are hearing the discussion about how many solutions, and 
the perspectives being expressed.  While the topic was well-raised, the 
discussion to date has not been structured in a way that makes clear to 
everyone what the purpose is.  In particular, the chairs have decided to 
re-ask the question.  We ask that even those who have responded in the 
discussion respond to this thread.  Preferably with both what their 
opinion is and an explanation of why.

The question we are asking you to comment on is:

Should the working group standardize one data plane behavior for 
compressing SRv6 information?

Please speak up.  We are looking to collect responses until close of 
business PDT on 20-August-2021.

Thank you,
Joel, Jim, and Bruno

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

[Bernier, Daniel]

Hello,

I am not aware of any IPR and support the WGLC

Dan B

From: spring  on behalf of James Guichard 

Date: Thursday, April 15, 2021 at 2:57 PM
To: "spring@ietf.org" 
Cc: "spring-cha...@ietf.org" 
Subject: [EXT][spring] WGLC for draft-ietf-spring-segment-routing-policy

Dear WG:

This email starts a 2 week Working Group Last Call for 
draft-ietf-spring-segment-routing-policy [1].

Please read this document if you haven’t read the most recent version and send 
your comments to the SPRING WG list no later than April 29th 2021.

If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributors for this document please response 
to the IPR call in the previous email thread.

Thanks!

Jim, Joel & Bruno


[1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Leadership change

[Bernier, Daniel]

Late reply but nonetheless

Thanks Rob and congratulations Joel and Jim 

Daniel Bernier

On 2020-06-14, 4:25 PM, "spring on behalf of Martin Vigoureux" 
 wrote:

WG,

Rob had decided to step down as chair some time ago. There hasn't been 
any formal communication on that so I'd like, first, to thank Rob for 
his work and dedication to the group. Thank you very much Rob.

Since that time, I have been actively looking for one (or two) person(s) 
to replace him. This has proven to be a very challenging endeavour!

But it has finally came to an end.

I am pleased to inform you that I have appointed Jim Guichard and Joel 
Halpern as co-chairs of SPRING WG, alongside Bruno.
Thank you Jim, Thank you Joel, and thank you Bruno.


Martin
as AD for SPRING

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

[Bernier, Daniel]

I support

Dan Bernier

On 2020-06-22, 10:46 AM, "spring on behalf of bruno.decra...@orange.com" 
 wrote:

Hi SPRING WG,

Authors of draft-voyer-spring-sr-replication-segment [1] have asked for WG 
adoption.

Please indicate your support, comments, or objection, for adopting this 
draft as a working group item by July 6th 2020.

Could those who are willing to work on this document, please notify the 
list. That gives us an indication of the energy level in the working group to 
work on this.

As a reminder, the call for IPR has been done last November. [2]

Thanks,
Regards,
Bruno, Jim, Joel

[1] https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment
[2] 
https://mailarchive.ietf.org/arch/msg/spring/tW-HHK7QzCw3ZBbFD0Dl7Eszd3k/



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Bernier, Daniel]

+1 on my side

Daniel Bernier

From: spring  on behalf of Lizhenbin 

Date: Wednesday, February 26, 2020 at 6:54 AM
To: "bruno.decra...@orange.com" , 'SPRING WG List' 

Cc: "6...@ietf.org" <6...@ietf.org>, draft-ietf-spring-srv6-network-programming 

Subject: [spring] Request to close the LC and move forward//RE: WGLC - 
draft-ietf-spring-srv6-network-programming

Hi Bruno and WG,
The LC has lasted for almost 3 months which greatly exceeds the expected 2 
week. In the process all the comments have been resolved while some issues is 
raised again and again with little value.
On the other hand, there have been multiple commercial implementation and 
inter-op test and almost 20 deployments for SRv6 which justify the solution 
proposed by the draft in practice.

We sincerely request to close the LC of the draft and move forward.



Best Regards,
Zhenbin (Robin)


From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Friday, December 06, 2019 1:15 AM
To: 'SPRING WG List' 
Cc: 6...@ietf.org; draft-ietf-spring-srv6-network-programming 

Subject: WGLC - draft-ietf-spring-srv6-network-programming


Hello SPRING,



This email starts a two weeks Working Group Last Call on 
draft-ietf-spring-srv6-network-programming [1].



Please read this document if you haven't read the most recent version, and send 
your comments to the SPRING WG list, no later than December 20.



You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating 
emails on the 6MAN mailing list for the comments which are only spring 
specifics.



If you are raising a point which you expect will be specifically debated on the 
mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that 
other points get forgotten (or that the thread get converted into parallel 
independent discussions)



Thank you,

Bruno



[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05




_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early Allocation Call

[Bernier, Daniel]

?Support


Daniel Bernier
Bell Canada


From: spring  on behalf of bruno.decra...@orange.com 

Sent: Thursday, December 19, 2019 11:53 AM
To: SPRING WG
Subject: [EXT][spring] draft-ietf-spring-srv6-network-programming - 2 week 
Early Allocation Call


Hi SPRING WG,



This begins a 2 week Early Allocation call for a "Ethernet" value from the 
"Protocol Numbers" registry.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-9.1

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-5.3

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml



In parallel of the Working Group Last Call which is currently running, the 
authors are requesting for early code point allocation from IANA as 
implementations are under way.



The criteria for early allocation are:

   a.  The code points must be from a space designated as "RFC

   Required", "IETF Review", or "Standards Action".  Additionally,

   requests for early assignment of code points from a

   "Specification Required" registry are allowed if the

   specification will be published as an RFC.



   b.  The format, semantics, processing, and other rules related to

   handling the protocol entities defined by the code points

   (henceforth called "specifications") must be adequately described

   in an Internet-Draft.



   c.  The specifications of these code points must be stable; i.e., if

   there is a change, implementations based on the earlier and later

   specifications must be seamlessly interoperable.



   d.  The Working Group chairs and Area Directors (ADs) judge that

   there is sufficient interest in the community for early (pre-RFC)

   implementation and deployment, or that failure to make an early

   allocation might lead to contention for the code point in the

   field.

https://tools.ietf.org/html/rfc7120#section-2



I believe the above conditions are met. (minus the AD judgement which is 
further down in the process)



As a reminder, this topic has mainly been discussed following IETF 105 
(Montréal) both during the meeting and on the mailing list.

During IETF 106 it has been discussed in the IntArea WG. 
https://datatracker.ietf.org/meeting/106/proceedings#intarea



Note that this code point is not to be specific to SRv6. Depending on AD 
guidance, this specific code point even be moved from 
draft-ietf-spring-srv6-network-programming into a specific 1 page draft.



If you support early adoption,  please include "support" along with any 
comments about the draft's technical solution.



If you do not support early allocation, please include "no support" in your 
email and indicate why.



Thank you,

--Bruno


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR poll for draft-ietf-spring-srv6-network-programming

[Bernier, Daniel]

Hi

As a contributor, I’m not aware of any undisclosed IPR that related to this 
document.

Thanks,

Dan B

On 2019-12-05, 11:50 AM, "spring on behalf of bruno.decra...@orange.com" 
 wrote:

Hi SPRING WG,

In parallel to the WGLC for draft-ietf-spring-srv6-network-programming, we 
would like to poll for IPR.

If you are aware of IPR that applies to 
draft-ietf-spring-srv6-network-programming [1] please respond to this email. If 
you are aware of IPR, please indicate whether it has been
disclosed in accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 
provide more details).

If you are an *author or contributor* please respond to this email 
regardless of whether or not you're aware of any IPR. 

This document will not advance until IPR confirmations have been received 
from all authors and contributors.

Thank you,
Bruno

[1] 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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？

[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？

[Bernier, Daniel]

ff-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 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> 
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 well as multi-layer signaling.

Regards,
Jeff

On Sep 19, 2019, at 19:49, Chengli (Cheng Li) 
mailto:chengl...@huawei.com>> wrote:
+1.

As I mentioned before, Binding SID is not only for shortening SID list.
We should see the important part of binding SID in inter-domain routing,  since 
it hides the details of intra-domain. Security and Privacy are always important.

Since the EH insertion related text will be removed from SRv6 NP draft, I don’t 
think anyone will still say we don’t need binding SID.
Let’s be honest, Encap mode Binding SID is very useful in inter-domain routing. 
It is not secure to share internal info outside a trusted network domain.

Cheng


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 19, 2019 11:36 PM
To: SING Team mailto:s.i.n.g.team.0...@gmail.com>>
Cc: 'SPRING WG List' mailto:spring@ietf.org>>
Subject: Re: [spring] A note on CRH and on going testing

+1

This is what we did on our multi-cloud trials.

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

Dan

On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" 
mailto:spring-boun...@ietf.org> on behalf of 
s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>> wrote:

Hi Andrew,

Good to hear that reality experiment :)

But is it secure to share internal SID-IP mappings outside a trusted network 
domain?

Or is there an analogue like Binding SID of SRv6, in SRv6+?

Btw, PSSI and PPSI can not do that now, right?

Best regards,
Moonlight Thoughts


(mail failure, try to cc to spring again.)

On 09/19/2019 17:49, Andrew Alston<mailto:andrew.als...@liquidtelecom.com> 
wrote:
Hi Guys,

I thought this may be of interest in light of discussions around deployments 
and running code - because one of the things we've been testing is inter-domain 
traffic steering with CRH on both our DPDK implementation and another 
implementation.

So - the setup we used last night:

6 systems in a lab - one of which linked to the open internet.  Call these S1 
-> S6
3 systems in a lab on the other side of the world - no peering between the 
networks in question.  Call these R1 -> R3

We applied a SID list on S1, that steered S1 -> S2 -> S3 -> S6 -> R1 -> R3, 
with the relevant mappings from the CRH SID's to the underlying addressing (S2 
had a mapping for the SID for S3, S3 had a mapping for the SID corresponding to 
S6, S6 had a mapping for the SID corresponding to R1 etc)

Then we sent some packets - and the test was entirely successful.

What this effectively means is that if two providers agree t

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

[Bernier, Daniel]

Or PPSIs

On 2019-09-19, 11:36 AM, "spring on behalf of Bernier, Daniel" 
mailto:spring-boun...@ietf.org> on behalf of 
daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca>> wrote:

+1

This is what we did on our multi-cloud trials.

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

Dan

On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" 
mailto:spring-boun...@ietf.org> on behalf of 
s.i.n.g.team.0...@gmail.com<mailto:s.i.n.g.team.0...@gmail.com>> wrote:

Hi Andrew,

Good to hear that reality experiment :)

But is it secure to share internal SID-IP mappings outside a trusted network 
domain?

Or is there an analogue like Binding SID of SRv6, in SRv6+?

Btw, PSSI and PPSI can not do that now, right?

Best regards,
Moonlight Thoughts


(mail failure, try to cc to spring again.)

On 09/19/2019 17:49, Andrew Alston<mailto:andrew.als...@liquidtelecom.com> 
wrote:
Hi Guys,

I thought this may be of interest in light of discussions around deployments 
and running code - because one of the things we've been testing is inter-domain 
traffic steering with CRH on both our DPDK implementation and another 
implementation.

So - the setup we used last night:

6 systems in a lab - one of which linked to the open internet.  Call these S1 
-> S6
3 systems in a lab on the other side of the world - no peering between the 
networks in question.  Call these R1 -> R3

We applied a SID list on S1, that steered S1 -> S2 -> S3 -> S6 -> R1 -> R3, 
with the relevant mappings from the CRH SID's to the underlying addressing (S2 
had a mapping for the SID for S3, S3 had a mapping for the SID corresponding to 
S6, S6 had a mapping for the SID corresponding to R1 etc)

Then we sent some packets - and the test was entirely successful.

What this effectively means is that if two providers agree to share the SID 
mappings - it is possible to steer across one network, out over an open path, 
and across a remote network.  Obviously this relies on the fact that EH's 
aren't being dropped by intermediate providers, but this isn't something we're 
seeing.

Combine this with the BGP signaling draft - and the SID's can then be signaled 
between the providers - work still going on with regards to this for testing 
purposes.  Just as a note - there would be no requirement to share the full SID 
mapping or topologies when doing this with BGP - the requirement would be only 
to share the relevant SID's necessary for the steering.

I can say from our side - with various other providers - this is something that 
we see *immense* use case for - for a whole host of reasons.

Thanks

Andrew


___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/Spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Bernier, Daniel]

+1

This is what we did on our multi-cloud trials.

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

Dan

On 2019-09-19, 11:18 AM, "spring on behalf of SING Team" 
mailto:spring-boun...@ietf.org> on behalf of 
s.i.n.g.team.0...@gmail.com> wrote:

Hi Andrew,

Good to hear that reality experiment :)

But is it secure to share internal SID-IP mappings outside a trusted network 
domain?

Or is there an analogue like Binding SID of SRv6, in SRv6+?

Btw, PSSI and PPSI can not do that now, right?

Best regards,
Moonlight Thoughts


(mail failure, try to cc to spring again.)

On 09/19/2019 17:49, Andrew Alston 
wrote:
Hi Guys,

I thought this may be of interest in light of discussions around deployments 
and running code - because one of the things we've been testing is inter-domain 
traffic steering with CRH on both our DPDK implementation and another 
implementation.

So - the setup we used last night:

6 systems in a lab - one of which linked to the open internet.  Call these S1 
-> S6
3 systems in a lab on the other side of the world - no peering between the 
networks in question.  Call these R1 -> R3

We applied a SID list on S1, that steered S1 -> S2 -> S3 -> S6 -> R1 -> R3, 
with the relevant mappings from the CRH SID's to the underlying addressing (S2 
had a mapping for the SID for S3, S3 had a mapping for the SID corresponding to 
S6, S6 had a mapping for the SID corresponding to R1 etc)

Then we sent some packets - and the test was entirely successful.

What this effectively means is that if two providers agree to share the SID 
mappings - it is possible to steer across one network, out over an open path, 
and across a remote network.  Obviously this relies on the fact that EH's 
aren't being dropped by intermediate providers, but this isn't something we're 
seeing.

Combine this with the BGP signaling draft - and the SID's can then be signaled 
between the providers - work still going on with regards to this for testing 
purposes.  Just as a note - there would be no requirement to share the full SID 
mapping or topologies when doing this with BGP - the requirement would be only 
to share the relevant SID's necessary for the steering.

I can say from our side - with various other providers - this is something that 
we see *immense* use case for - for a whole host of reasons.

Thanks

Andrew


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/Spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Per segment service instructions

[Bernier, Daniel]

Tarek,

My feeling is it kind of defeats the purpose. The value prop of SRv6+ was the 
separation of forwarding (LOCATOR) from service (FUNCTION) in different EH. Now 
to avoid having domain-wide alignment of PSSI values, you would re-introduce a 
SID in the 32bit section of PSSI to make it unique again.

Regards,
Daniel Bernier



On 2019-09-16, 12:44 PM, "Ron Bonica" 
mailto:rbon...@juniper.net>> wrote:


Good idea!!




Juniper Business Use Only
From: Tarek Saad 
Sent: Monday, September 16, 2019 11:59 AM
To: EXT - daniel.bern...@bell.ca ; Ron Bonica 
; Robert Raszuk 
Cc: SPRING WG ; 6man <6...@ietf.org>
Subject: Re: [spring] Per segment service instructions

Hi all,

A possible way to avoid domain wide scope of PSSI, would be to encode a per 
node ID within the PSSI (per node namespace of Service IDs).
This allows the node parsing the DOH to identify PSSI(s) that needs to be 
invoked locally and to resolve the Service ID within its node scope. The per 
node ID can be a SRV6+ short SID that is instantiated locally on the node.

So, a PSSI = Short-SID.SE1

DOH can contain:
Short-SID1.SE1
Short-SID2.SE2
Etc.

Regards,
Tarek



From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Bernier, Daniel" 
mailto:daniel.bern...@bell.ca>>
Date: Saturday, September 14, 2019 at 1:03 AM
To: Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>,
 Robert Raszuk mailto:rob...@raszuk.net>>
Cc: SPRING WG mailto:spring@ietf.org>>, 6man 
<6...@ietf.org<mailto:6...@ietf.org>>
Subject: Re: [spring] Per segment service instructions

Hi Ron,

If PSSI provide non-routing services such as SE1 from Robert’s example which 
offers DPI, FW and Packet Replication then, I need a domain-wide PSSI defining 
DPI + FW + Sampling but if somewhere else in my network I just need FW, then I 
need another domain-wide PSSI for only FW.
In that model, I will end up with and endless list of permutations which must 
be agreed upon to ensure interop (i.e. vendor A cannot use a PSSI X for FW 
while vendor B think’s its DPI).
Thx
Dan B



On 2019-09-13, 2:10 PM, "ipv6 on behalf of Ron Bonica" 
mailto:ipv6-boun...@ietf.org> on behalf of 
rbonica=40juniper@dmarc.ietf.org<mailto:rbonica=40juniper@dmarc.ietf.org>>
 wrote:

Robert,

In your email, you ask how I would solve a TE problem with a Per Segment 
Service Instruction (PSSI).. In SRv6+:


-  The CRH and the SIDs that it contains are used to solve TE problems

-  The PSSI is used too provide non-routing services (e.g., 
firewalling, sampling, DPI)

This leaves the following questions to be answered:


-  How would I solve the TE problem that you describe in your email?

-  Given another example, explain how PSSI works?

Which question would you like me to tackle first?

Ron


From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Friday, September 13, 2019 8:45 AM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: SPRING WG mailto:spring@ietf.org>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>
Subject: Per segment service instructions

Dear Ron,

I have read yet one more draft from the SRv6+ package defining another 
Destination Option type - this time Per Segment Service Instruction(s) 
described in draft-bonica-6man-seg-end-opt

I have one technical question regarding it.

Imagine I have following topology - drawing only what is relevant to the 
question:

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

When packet enters the network PE1 is instructed to program my flow A to 
execute following following functions on Segment End 1 (SE1) and Segment End 2 
(SE2):

SE1 - When packet is routed out of SE1 consider only interfaces of bw 10G and up

SE2 - When packet is routed out of SE2 make sure that path to segment end node 
is no more then 2 hops away.

From reading the draft I think the answer is that you mandated the segment end 
functions in SRv6+ to have domain-wide significance such that the function 
itself contains not only the instruction but also as it is of domain-wide 
significance the location of the instruction to execute it on.

So far so good ... Flow-A get's CRH and PSSI encoding the above requirement.

When packet enters SE1 Destination Options preceding RH is read and PSSIs are 
attempted to get executed ! Both instructions are tried but only one is known 
so only one get's executed on SE1. Same story on SE2.

Not sure if eveyone would be ok with such model to read and attempt to execute 
instructions which are not for a given end segment but let's assume some may 
accept it.

But now how unfortunate it may sound PE1 is receving the flow-B and for flow B 
the requirements are opposite:

SE1 - When packet is routed out of SE1 make sure that path to segment end node 
is no more then 2 hops away.

SE2 - When packet is routed out of SE2 consi

Re: [spring] Beyond SRv6.

[Bernier, Daniel]

Ron

On 2019-09-12, 10:57 AM, "Ron Bonica" 
mailto:rbon...@juniper.net>> wrote:

Dan,

Both good questions !!!

In Ole’s example, a segment endpoint that is not the SR egress node executes a 
service instruction. In SRv6+, this kind of service instruction is called a Per 
Segment Service Instruction (PSSI). It is encoded in a Destination Options 
header that precedes the Routing header. Because IPv6 processes extension 
header in the order that they appear in the packet, this Destination Options 
header is processed by each segment endpoint, including the SR Path egress node.

The Destination Options header includes one or more options. Options are 
processed in the order that they appear in the header. Each option has a unique 
type and the first two bits of the type identifier determine how the processing 
node will behave if it does not recognize the option.

SRv6+ defines a new IPv6 Option, called the PSSI option. The first two bits of 
its type identifier are 00. So, if the processing node does not recognize the 
option, or is not configured to process the option, it skips over the option 
and continues to process the packet. Typically, core routers won’t execute Per 
Segment Service Instructions. So, by default, they will be configured to skip 
over the PSSI option. However, devices that provide per segment services (e.g., 
firewall services , DPI services) will process the PSSI.

But the node still needs to load it and check if it should process before going 
forward. Even more so, when packet arrives at FW service for processing. It has 
the PSSI assigned to FW + the CRH. Once processed, the FW needs to now encap 
the traffic with DOH and a PSSI for the next service segment in the chain (ie 
DPI) how does it know what PSSI to apply ? This would require some end-to-end 
topological state to know what PSSI to apply and when to apply it.

The PSSI by no means attempts to replace the NSH.

In SRv6+, service instructions that are executed by the SR path egress node 
only are called Per Path Service Instructions (PPSI). These instructions are 
encoded in another Destination Options header that precedes the upper layer 
header. This Destination Options header is processed by the SR path egress node 
only.

SRv6+ defines another new IPv6 Option, called the PSSI option. The first two 
bits of its type identifier are 10. So, if the processing node does not 
recognize the option, it discards the packet and sends an ICMP message to the 
packet source.

The benefit of separating the Routing Header from the PPSI are as follows:


-  An AH or ESP header can be interposed between the Routing Header and 
the Destination Options header.  The AH or ESP can be used to protect PPSI.

-  The Routing header isn’t bloated with PPSI information. Therefore, 
ASIC based intermediate nodes don’t have to load PPSI information into on chip 
memory

But they would still need to process PSSI. Again in SRv6, the PPSI is either a 
standard SID entry and if your concerned about chip memory, uSID gives you the 
compressed version.


-  That there is no need to define a myriad of SID’s, some of which are 
valid only when SL is equal to 0 and others that are valid when SL > 0. If an 
instruction is valid only when SL = 0, it isn’t a SID. It is a PPSI.

Again SRH does not define a myriad of SIDs but forwarding behaviours that would 
need to be defined regardless in a SRv6+ device if it wanted to perform the 
same capabilities. Difference is SRH does not require to specify them in the EH 
while SRv6+ would through the PSSI or PPSI


 Ron







Juniper Business Use Only
From: spring  On Behalf Of Bernier, Daniel
Sent: Wednesday, September 11, 2019 11:41 PM
To: xie...@chinatelecom.cn; List 
Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad 
; Robert Raszuk 
Subject: Re: [spring] Beyond SRv6.


+1



The ability of using a single SRH to convey behaviour information wether they 
are per-segment or per-path has proven to be very simple and quick to define in 
various data plane targets.



At first analysis, trying to replicate with CRH + DOH variants, the logic 
required for service programs is more com​plex.



What happens if I need TLVs mid-point in a path but not at its end (e.g. 
referring to the Ole's ACME analogy) ? Would they now be defined in a 
seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested 
midpoint devices will have to lookup beyond the TLVs to get to CRH for next 
segment ?



Similar question would be on how would we implement proxy behaviours either 
dynamic or static ? If I read 
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!X44n64pmIbfHbV6M9TDLFFeeQIEn4zROUOebJ7V5MYncIU31g1sgm7aA1kXfbfNt$>
 correctly, we then need NSH for richer service c

Re: [spring] Beyond SRv6.

[Bernier, Daniel]

Ron,

But these are not SIDs … these are functions (i.e. processing logic) to be 
executed by a device when receiving a packet where the DA is bound to a Local 
SID associated to one of them.  No need to specify custom extensions per 
function.

With a PPSI, you will still need to specify a different unique identification 
so that when a device needs to process, it knows its needs to do a Layer 3 
lookup, Layer 3 cross-connect, Layer 2 operations, etc.


On 2019-09-12, 2:51 PM, "Ron Bonica" 
mailto:rbon...@juniper.net>> wrote:

Daniel,

Not really. A single IPv6 Option, the PPSI, replaces all of the following SIDs:


-  END.DX2

-  END.DX2V

-  END.DX2U

-  END.DX2M

-  END.DT4

-  END.DX4

-  END.DT6

-  END.DX6

-  END.DT46

-  END.T


   
Ron



Juniper Business Use Only
From: Bernier, Daniel 
Sent: Thursday, September 12, 2019 2:26 PM
To: Ron Bonica ; Mark Smith 
Cc: Rob Shakir ; SPRING WG ; 6man 
<6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn; 
Tarek Saad 
Subject: RE: [spring] Beyond SRv6.

That was precisely my point

Having been involved in pushing SRv6 END behaviours in various targets, I can 
first hand say that the primitives behind SRH processing is quite simple to 
extend. In your extensibility model, every predefined or custom behavior 
becomes a new DOH. On SRH, the EH does not change I just need to inform the 
data plane that when receiving a packet with a specific SID in SRH, do this 
internal processing.


On 2019-09-12, 12:34 PM, "Ron Bonica" 
mailto:rbon...@juniper.net>> wrote:

Mark,

I think that you may have exposed yet another elephant in the room……

IPv6 defines a robust extensibility architecture, that includes multiple 
extension headers. Initially, IPv6 adoption was slow and router vendors were 
not highly motivated commit extension headers to ASICs. Also, in those days, 
ASICs were not so capable as they are today.

From the above-mentioned data points, we should not infer that it is beyond the 
capability of a modern vendor to develop an ASIC that supports a more complete 
set of extension headers. Two things have changed. As IPv6 adoption progresses, 
vendors are becoming more committed to IPv6. Beyond that, ASICs have become 
more capable over the decades.

We shouldn’t abandon the IPv6 extensibility architecture based on a claim that 
ASICs cannot and will never be able to  process multiple extension headers.


  Ron




From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
Mark Smith
Sent: Thursday, September 12, 2019 1:30 AM
To: EXT - daniel.bern...@bell.ca<mailto:daniel.bern...@bell.ca> 
mailto:daniel.bern...@bell.ca>>
Cc: Rob Shakir mailto:ro...@google.com>>; SPRING WG 
mailto:spring@ietf.org>>; 6man 
<6...@ietf.org<mailto:6...@ietf.org>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; 
xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Tarek Saad 
mailto:tsaad@gmail.com>>
Subject: Re: [spring] Beyond SRv6.

It's simple because IPv6 doesn't look past the fixed IPv6 header to perform its 
forwarding, and matches on the Destination Address to determine if to perform 
deeper packet host processing.


You're building much more complicated forwarding services if you're going to be 
marching on TLVs etc. past the IPv6 fixed header.

However vendors and carrier engineering groups like selling and deploying new 
gear, so I suppose that's ok. They don't have to operate it or fix it when it 
breaks.
On Thu, 12 Sep 2019, 13:41 Bernier, Daniel, 
mailto:daniel.bern...@bell.ca>> wrote:

+1



The ability of using a single SRH to convey behaviour information wether they 
are per-segment or per-path has proven to be very simple and quick to define in 
various data plane targets.



At first analysis, trying to replicate with CRH + DOH variants, the logic 
required for service programs is more com​plex.



What happens if I need TLVs mid-point in a path but not at its end (e.g. 
referring to the Ole's ACME analogy) ? Would they now be defined in a 
seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested 
midpoint devices will have to lookup beyond the TLVs to get to CRH for next 
segment ?



Similar question would be on how would we implement proxy behaviours either 
dynamic or static ? If I read 
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04__;!8WoA6RjC81c!WhasJYFTRmXzKd1g-oMU5hza4EoH-63AFe6qzFFZtlfTRAiabJjCZB0f5dp14y8L$>
 correctly, we then need NSH for richer service chains constructs (think 
Gi-LAN). This means I need CRH, some variants of DOH + NSH​.



I fail to see the simplicity the

Re: [spring] Per segment service instructions

[Bernier, Daniel]

Hi Ron,

If PSSI provide non-routing services such as SE1 from Robert’s example which 
offers DPI, FW and Packet Replication then, I need a domain-wide PSSI defining 
DPI + FW + Sampling but if somewhere else in my network I just need FW, then I 
need another domain-wide PSSI for only FW.
In that model, I will end up with and endless list of permutations which must 
be agreed upon to ensure interop (i.e. vendor A cannot use a PSSI X for FW 
while vendor B think’s its DPI).
Thx
Dan B



On 2019-09-13, 2:10 PM, "ipv6 on behalf of Ron Bonica" 
mailto:ipv6-boun...@ietf.org> on behalf of 
rbonica=40juniper@dmarc.ietf.org>
 wrote:

Robert,

In your email, you ask how I would solve a TE problem with a Per Segment 
Service Instruction (PSSI). In SRv6+:


-  The CRH and the SIDs that it contains are used to solve TE problems

-  The PSSI is used too provide non-routing services (e.g., 
firewalling, sampling, DPI)

This leaves the following questions to be answered:


-  How would I solve the TE problem that you describe in your email?

-  Given another example, explain how PSSI works?

Which question would you like me to tackle first?

Ron


From: Robert Raszuk 
Sent: Friday, September 13, 2019 8:45 AM
To: Ron Bonica 
Cc: SPRING WG ; 6man <6...@ietf.org>
Subject: Per segment service instructions

Dear Ron,

I have read yet one more draft from the SRv6+ package defining another 
Destination Option type - this time Per Segment Service Instruction(s) 
described in draft-bonica-6man-seg-end-opt

I have one technical question regarding it.

Imagine I have following topology - drawing only what is relevant to the 
question:

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

When packet enters the network PE1 is instructed to program my flow A to 
execute following following functions on Segment End 1 (SE1) and Segment End 2 
(SE2):

SE1 - When packet is routed out of SE1 consider only interfaces of bw 10G and up

SE2 - When packet is routed out of SE2 make sure that path to segment end node 
is no more then 2 hops away.

From reading the draft I think the answer is that you mandated the segment end 
functions in SRv6+ to have domain-wide significance such that the function 
itself contains not only the instruction but also as it is of domain-wide 
significance the location of the instruction to execute it on.

So far so good ... Flow-A get's CRH and PSSI encoding the above requirement.

When packet enters SE1 Destination Options preceding RH is read and PSSIs are 
attempted to get executed ! Both instructions are tried but only one is known 
so only one get's executed on SE1. Same story on SE2.

Not sure if eveyone would be ok with such model to read and attempt to execute 
instructions which are not for a given end segment but let's assume some may 
accept it.

But now how unfortunate it may sound PE1 is receving the flow-B and for flow B 
the requirements are opposite:

SE1 - When packet is routed out of SE1 make sure that path to segment end node 
is no more then 2 hops away.

SE2 - When packet is routed out of SE2 consider only interfaces of bw 10G and 
up.

Well what do you - simple - you allocate another two domain wide functions and 
encode it in the packet at PSSI DOH on PE1.

But if my description matches the plan you now end up with per flow !!! state 
in the network which is the price to pay for splitting SIDs with its functions 
into completely different headers.

I don't know about others but I think we went in the past via multiple attempts 
to put any per flow state into the large network and it all failed when faced 
scale.

Also SR specifically in its architecture RFC8402 says that segment routing is 
"maintaining per-flow state only at the ingress node(s) to the SR domain."

Kind regards,
Robert.



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

Re: [spring] Beyond SRv6.

[Bernier, Daniel]

+1


The ability of using a single SRH to convey behaviour information wether they 
are per-segment or per-path has proven to be very simple and quick to define in 
various data plane targets.


At first analysis, trying to replicate with CRH + DOH variants, the logic 
required for service programs is more com​plex.


What happens if I need TLVs mid-point in a path but not at its end (e.g. 
referring to the Ole's ACME analogy) ? Would they now be defined in a 
seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested 
midpoint devices will have to lookup beyond the TLVs to get to CRH for next 
segment ?


Similar question would be on how would we implement proxy behaviours either 
dynamic or static ? If I read 
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly, we then 
need NSH for richer service chains constructs (think Gi-LAN). This means I need 
CRH, some variants of DOH + NSH​.


I fail to see the simplicity there.


Dan B


From: spring  on behalf of xie...@chinatelecom.cn 

Sent: Wednesday, September 11, 2019 8:57 PM
To: List
Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk
Subject: [EXT]Re: [spring] Beyond SRv6.


Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for 
the bearing and interconnection of video platforms which are  located in 
different cities, service agilities,secure sepertion, traffic steering and 
other features of SRv6 have been demonstrated in this trial. Based on this, 
SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to 
reduce the the overhead of long SID in the long term, but it is better to be 
compatible withe SRH, instead of designing a complete new one. CRH is a 
complete new design, it move the complexities from SRH to DOH.
Moreover, I hope more efforts of SRv6 should be given on how to support new 
services,for instance, Application-aware network (APN). Meanwhile, we should 
consider more on how to implmement smooth transition and protect the network 
assetof carriers.

Best regards
Chongfeng


From: Dirk Steinberg
Date: 2019-09-09 21:31
To: Gyan Mishra
CC: SPRING WG List; 
6...@ietf.org; Robert Raszuk; 
Rob Shakir; Tarek Saad
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:

- Remote LFA tunnel is not used with SR, only TI-LFA which
  only operates on the node that is the PLR (point of local repair).

- Any encapsulation on the ingress PE with or without EH has nothing
  to do with TI-LFA except for the special case where the ingress PE
  itself is the PLR.

- TI-LFA is not an IGP extension and does not require one.
  It is a purely local computation based on IGP topology.

- The PLR for TI-LFA may need to insert some SIDs into the SID
  list to steer the packet around the failure. For the LFA base case
  no SIDs are needed at all. If SID insertion is needed, the PLR
  will push the required number of labels in the MPLS case.

  For SRv6, the equivalent operation to the label push is to
  insert an EH with the required SID list. The packet will already
  have been encapsulated on the ingress PE and in the most
  common Internet or VPN base use case it will not even have
  an EH so that this EH insertion will result only in a single EH.

  Alternatively, the PLR could also be configured to perform
  encapsulation with a new IPv6 header using the repair SID
  as IPv6 destination address, without needing any EH.
  This will work for the vast majority of cases.
  Remember that one 128-bit SID in SRv6 is in most cases
  equivalent to 2 MPLS labels, i.e. a node label plus an
  adjacency SID can be encoded in a single SRv6 SID.

  Only in extreme cases would the PLR need to add an
  EH to the new IPv6 header with more SIDs.

- EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.

Hope it helps.

Cheers
Dirk

Am 08.09.2019 um 09:19 schrieb Gyan Mishra 
mailto:hayabusa...@gmail.com>>:

From reading through all the discussion threads the SR insertion is two fold 
one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up 
requiring double EH insertions on the Ingress PE tunnel head end SRv6 source 
node and then second scenario being a possible EH insertions occurrence on 
intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA 
with SR but since that is an IGP extension I am guessing an opaque LSA and is 
not the traditional MPLS FRR link/node/path protection that adds an additional 
mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can 
someone clarify that use case for me.  Also the EH insertion on intermediate 
node what is the use case or reason for that.  My guess is it’s for 

Re: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

[Bernier, Daniel]

Hi Fernando,

Let’s say I have a native IPv6 application flow to which I want to apply a 
service policy (i.e. chain of functions), carry metadata through TLVs or 
perform a very simplistic filtering action via the tag field. All of which are 
real use cases by the way.
Should I not leverage insertion instead ?

Thanks,

Daniel Bernier

On 2019-09-06, 11:10 PM, "spring on behalf of Fernando Gont" 
mailto:spring-boun...@ietf.org> on behalf of 
fg...@si6networks.com> wrote:

Folks,

I have one specific question regarding this I-D:
What is the motivation for doing EH-insertion, instead of creating a new
packet with the necessary EHs, and include the original packet in the
payload?

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Poll: draft-guichard-spring-nsh-sr

[Bernier, Daniel]

?Hi Rob,


Support WG adoption and not aware of any undisclosed IPR.


Thanks,


Daniel Bernier | Bell Canada

From: spring  on behalf of Rob Shakir 

Sent: Thursday, June 27, 2019 2:13 AM
To: draft-guichard-spring-nsh...@ietf.org; SPRING WG List
Subject: [EXT][spring] IPR Poll: draft-guichard-spring-nsh-sr

Hi Authors, SPRING WG,

In parallel to the call for working group adoption for 
draft-guichard-spring-nsh-sr we would like to poll for IPR.

If you are aware of IPR that applies to draft-guichard-spring-nsh-sr please 
respond to this email. If you are aware of IPR, please indicate whether it has 
been disclosed in accordance to the IETF IPR rules (detailed are described in 
RFCs 3979, 4879, 3669 and 5378).

If you are an author or contributor please respond to this email regardless of 
whether or not you're aware of any IPR. If you are not an author or 
contributor, please explicitly respond only if you're aware of IPR that has not 
yet been disclosed.

This document will not advance into the working group until such time as we 
have received IPR confirmations from all authors and contributors.

Thanks!
Rob & Bruno
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Poll: draft-xuclad-spring-sr-service-programming

[Bernier, Daniel]

Hi Rob


I am not aware of any undisclosed IPR

?

Cheers


Daniel Bernier | Bell Canada


From: Rob Shakir 
Sent: Thursday, June 27, 2019 2:13 AM
To: draft-xuclad-spring-sr-service-programm...@ietf.org; SPRING WG List
Subject: [EXT]IPR Poll: draft-xuclad-spring-sr-service-programming

Hi Authors, SPRING WG,

In parallel to the call for working group adoption for 
draft-xuclad-spring-sr-service-programming we would like to poll for IPR.

If you are aware of IPR that applies to draft-xuclad-sr-service-programming 
please respond to this email. If you are aware of IPR, please indicate whether 
it has been disclosed in accordance to the IETF IPR rules (detailed are 
described in RFCs 3979, 4879, 3669 and 5378).

If you are an author or contributor please respond to this email regardless of 
whether or not you're aware of any IPR. If you are not an author or 
contributor, please explicitly respond only if you're aware of IPR that has not 
yet been disclosed.

This document will not advance into the working group until such time as we 
have received IPR confirmations from all authors and contributors.

Thanks!
Rob & Bruno

External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] WG Adoption Call: draft-xuclad-spring-sr-service-programming

[Bernier, Daniel]

Hi

As co-author I support adoption of this draft

Daniel Bernier

On 2019-06-27, 2:14 AM, "spring on behalf of Rob Shakir" 
mailto:spring-boun...@ietf.org> on behalf of 
robjs=40google@dmarc.ietf.org> 
wrote:

Hi SPRING WG,

This email initiates a two week working group adoption call for 
draft-xuclad-spring-sr-service-programming. This follows the discussion that we 
had in the last few IETF meetings, and particularly the focused discussion we 
had at IETF 104 regarding service chaining and SPRING.

Please indicate your support, comments, or objections for adopting this draft 
by Wednesday July 10th, 2019. We are particularly interested in hearing from WG 
members who are not authors of this draft, and those folks that are willing to 
spend time working on this draft after adoption.

We are also looking for volunteers who can provide a technical review of the 
content of the draft at a later stage of its progress through the working group 
(e.g., before WGLC).

In parallel - we'll send an IPR poll to the working group and authors. The 
currently disclosed IPR can be found in the 
datatracker.

Thanks!
Rob & Bruno.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IPR Poll for draft-filsfils-spring-srv6-network-programming

[Bernier, Daniel]

As a contributor I am not aware of any IPR

Thanks,

Dan Bernier

On 2019-03-13, 2:50 PM, 
"bruno.decra...@orange.com" 
mailto:bruno.decra...@orange.com>> wrote:


Hi authors, SPRING WG,



In parallel to the call for adoption for 
draft-filsfils-spring-srv6-network-programming (1), we would like to poll for 
IPR.



If you are aware of IPR that applies to 
draft-filsfils-spring-srv6-network-programming please respond to this email.

If you are aware of IPR, please indicate whether it has been disclosed in 
accordance with IETF IPR rules (RFCs 3979, 4879, 3669 and 5378 provide more 
details).



If you are an *author or contributor* please respond to this email regardless 
of whether or not you're aware of any IPR.

If you are not an author or contributor, please explicitly respond only if you 
are aware of IPR that has not yet been disclosed.



This document will not advance into the working group until IPR confirmations 
have been received from all authors and contributors.



Thank you,



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07





--Bruno & Rob.


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

[Bernier, Daniel]

Support

Dan Bernier | Bell Canada

On 2019-03-13, 2:49 PM, "spring on behalf of 
bruno.decra...@orange.com" 
mailto:spring-boun...@ietf.org> on behalf of 
bruno.decra...@orange.com> wrote:


Hi SPRING WG,



This email initiates a three week call for working group adoption for 
draft-filsfils-spring-srv6-network-programming. (Three weeks to account for the 
IETF week)



Please indicate your support, comments, or objection, for adopting this draft 
as a working group item by April, 3rd, 2019 (aka 2019-04-03)

We are particularly interested in hearing from working group members that are 
not co-authors of this draft.



We are also looking for volunteers who would be ready to perform a technical 
review of this work at some later stage, such as before or during WG the last 
call.



In parallel to this adoption call, I will send an IPR call for this document. 
We will need all authors and contributors to confirm their IPR position on this 
document.

There is currently 1 IPR filled (2)



(1)  
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07

(2)  
https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-network-programming=draft





Thank you,

--Bruno & Rob.


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Last Call: (Segment Routing with MPLS data plane) to Proposed Standard

[Bernier, Daniel]

+1

Dan B

On 2019-02-26, 4:20 PM, "spring on behalf of Adrian Farrel" 
 wrote:

This draft has been around the block a bit, but certainly needs to progress
because a lot of other things are dependent on it.

Fortunately after plenty of review and updates (thanks to the authors), I
think it is now ready to become an RFC.

Adrian

-Original Message-
From: spring  On Behalf Of The IESG
Sent: 21 February 2019 18:42
To: IETF-Announce 
Cc: martin.vigour...@nokia.com;
draft-ietf-spring-segment-routing-m...@ietf.org; spring@ietf.org;
spring-cha...@ietf.org; shrad...@juniper.net
Subject: [spring] Last Call: 
(Segment Routing with MPLS data plane) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Segment Routing with MPLS
data plane'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2019-03-07. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning
of
the Subject line to allow automated sorting.

Abstract


   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through a controlled set of instructions, called
   segments, by prepending the packet with an SR header.  In the MPLS
   dataplane, the SR header is instantiated through a label stack. This
   document specifies the forwarding behavior to allow instantiating SR
   over the MPLS dataplane.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ball
ot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2880/
   https://datatracker.ietf.org/ipr/2453/
   https://datatracker.ietf.org/ipr/2454/





___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Bernier, Daniel]

Hi Rob,



A bit late but +1 to Zafar's and Linda's comments on adding overlay/app 
interaction with underlay in the WG charter.



I presented at last IETF in PANRG (ref: 
https://datatracker.ietf.org/meeting/101/materials/slides-101-panrg-service-aware-networking-using-segment-routing-00)
 on this topic and I do think there is potential for a lot of extensions with 
regards to inter-carrier SR policy awareness and how it interacts at the 
host/app level as well.



Cheers,



Daniel Bernier


From: spring  on behalf of Zafar Ali (zali) 

Sent: Wednesday, June 6, 2018 2:41 PM
To: Rob Shakir; Linda Dunbar
Cc: Jeff Tantsura; Zafar Ali (zali); SPRING WG List
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

Re: Linda comment on SR assisted SD-WAN.

At IETF101, Bruno and you presented a slide based on the WG feedback on the 
mailing list 
(https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01).
 During the Spring meeting, the WG agreed to add milestones against those 
items. In general, I see some milestones are not included in the proposed 
chartered text.

In the context of Linda’s feedback, the slide has the following text (with 
support during the WG meeting):


  *   Interactions between overlay/applications and optimized underlay

 *   E.g. SR-assisted SD-WAN, path awareness

We should add a milestone for specification of architecture, and the required 
protocol extensions for Segment Routing for interactions between overlay/ 
applications and optimized SR underlay MPLS and IPv6 data planes. I fully agree 
with you that the actual protocol extension work will be done at the WG that 
owns the protocol.

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

Date: Sunday, June 3, 2018 at 5:32 PM
To: Linda Dunbar 
Cc: Jeff Tantsura , SPRING WG List 
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Linda,

On Fri, Jun 1, 2018 at 12:35 PM Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).
[jeff] I’d add “dataplanes”
SPRING WG serves as
a forum to discuss SPRING networks operations, define new applications, and
specify extensions of Segment Routing technologies.
[Linda] Does the “new applications” in the sentence above refer to the “Use 
cases” for SPRING?
Is the “Extensions” being discussed in SPRING also include the “extensions” to 
other protocols?

robjs> The aim here is to define that SPRING is where we discuss new things 
that are done with SR. I don't think we want to constrain things to say that 
only use-case work is done in SPRING (actually, we've had little success with a 
number of the use case documents). The extensions referred to are extensions to 
SR technologies.. Per the later wording in the charter, the intention here is 
to clarify that functional specifications for those extensions can be done in 
SPRING, but the actual extension work is owned by the WG that owns that 
technology.

robjs> You can imagine the SR-TE policy work breaks down this way: we discuss 
the "application" which is steering traffic onto sets of SR paths, and define a 
functional specification document for how that works. If that is realised in 
BGP (as it is being today), IDR owns the protocol specification, if it's in 
PCEP, then it's done in that WG.

 *snip*
o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes.

[Linda] o Source-routed stateless SD-WAN paths traversing through SR domain 
(i.e. SR as part of SD-WAN’s underlay network)

robjs> Our focus here is to provide a constrained set of areas where there is a 
need for work within SPRING. The discussions that we had in the working group 
in London were focused around capturing the set of technologies that have 
strong support and folks to work on. If we have new proposals around this work, 
then we can always consider working on them if they need extensions to the SR 
architecture. At the moment, the preference is to keep this list constrained 
such that we can focus the working group.

 *snip*

o The inter-working between SRv6 and SR-MPLS.

[Linda] o The inter-working between SR and legacy networks (which is far more 
likely than SRv6 & SR-MPLS interworking)

robjs> The LDP interop draft is something that is going to the IESG at the 
moment. There is existing work in TEAS (in WGLC) that covers co-existence of 
RSVP-TE and SR. Are there specific areas that we have gaps? The reason that we 
call out SRv6/SR-MPLS interop is that there has been some discussion of this, 
and we have not got an answer for this yet.

Thanks for the comments.

Kind regards,
r.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy

[Bernier, Daniel]

Support WG adoption

Also not aware of any IPR

Daniel Bernier

On 2018-05-16, 11:20 AM, "spring on behalf of Rob Shakir" 
mailto:spring-boun...@ietf.org> on behalf of 
ro...@google.com> wrote:

Hi SPRING WG,

This email initiates a two week call for working group adoption for 
draft-filsfils-spring-segment-routing-policy. Please indicate your support, or 
otherwise, for adopting this draft as a working group item by 30th May 2018. We 
are particularly interested in hearing from working group members that are not 
co-authors of this draft.

As part of the discussions of adopting this draft into SPRING with the ADs and 
chairs of other WGs, there are a number of requests to the authors.

1. Please clarify in the text traffic steering with "SR policy" and its 
relationship to other traffic engineering functions. It seems to me that this 
work is generally describing how one selects and steers traffic into policies, 
rather than path calculation. Additional clarification of whether this is the 
case (or not), would be welcome to ensure that the relationship with other work 
is clear. We would ask the authors to consider whether sections 14.1-14.4 are 
required scope of this document.

2.. Consider what the core content of this document is, and how it can be make 
as concise and clear as possible. There are some specific suggestions that can 
be made here, but we would like to see this discussed with the working group.

Additionally, there are currently 17 authors listed on this document. Please 
trim this to <= 5 front-page authors, utilising a "Contributors" section if 
required for the others.. An approach to achieving this would be to list ~2 
editors as the front-page authors.

In parallel to this adoption call, I will send an IPR call for this document. 
We will need all 17 authors to confirm their IPR position on this document.

Thanks,
Bruno & Rob.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Request WG adoption for draft-xuclad-spring-sr-service-chaining-01

[Bernier, Daniel]

Hello SPRING chairs,


When do you think this clarification of the charter might have progressed 
enough to provide an update on the WG adoption of 
draft-xuclad-spriong-sr-service-chaining ?

Knowing that MPLS WG and SPRING WG chairs have agreed that 
draft-xuclad-spring-sr-service-chaining should remain in SPRING


Cheers,


- Dan B


From: spring  on behalf of bruno.decra...@orange.com 

Sent: Thursday, May 3, 2018 3:21 AM
To: 徐小虎(义先); SPRING WG List
Subject: Re: [spring] Request WG adoption for 
draft-xuclad-spring-sr-service-chaining-01

Hi Xiaohu,

We’d like to first clarify the content of the new charter.

Best regards,
--Bruno


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of ???(??)
Sent: Thursday, May 03, 2018 6:07 AM
To: ???(??); SPRING WG List
Subject: Re: [spring] Request WG adoption for 
draft-xuclad-spring-sr-service-chaining-01


Hi SPRING WG co-chairs,

I wonder what the current status of this WG adoption request.

Best regards,
Xiaohu
--
From:徐小虎(义先) >
Send Time:2018年4月4日(星期三) 09:45
To:SPRING WG List >
Cc:s...@ietf.org >
Subject:Request WG adoption for draft-xuclad-spring-sr-service-chaining-01


Hi SPRING WG co-chairs,

We authors believe this draft 
(https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01) has 
been stable enough and therefore we would like to request a WG adoption call 
for it.

We believe this work belongs to SPRING WG since the concept of service segment 
has been mentioned in the Segment Routing architecture from day one and the 
approaches as described in this draft are exactly to leverage the stateless 
source routing capability of segment routing to achieve a stateless SFC. To 
some extent, SFC can be looked as a special case of source routing as it 
requires the selected traffic to traverse an ordered list of service nodes.


We believe the SFC WG review is still needed after the adoption since we still 
hope to reuse the NSH for some special purposes (e.g., use it as a metadata 
container).

BTW, implementations based on this draft have existed, as noted in section 8 of 
the draft.

Best regards,
Xiaohu (on behalf of coauthors)






_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[Bernier, Daniel]

​Hi Med,


Please see inline


Cheers


Daniel Bernier


From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
Sent: Wednesday, March 21, 2018 5:06 AM
To: Bernier, Daniel
Cc: mpls; SPRING WG List; b...@ietf.org; s...@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Hi Daniel,

I’m afraid that the comparison with DC routing is misleading here. It is still 
possible to use your favorite transport encapsulation with the approach 
endorsed by the IETF in 8300.

DB> ​But that means in that case I must use RFC8300, my view is there is an 
option for RFC8300 but there CAN be others.

Re-using NSH instead of mimic it in each individual transport protocol is much 
more pragmatic. It avoids wasting extra specification in defining exactly the 
same set of information for each of one’s favorite transport encapsulating 
protocol.

DB> ​This is where I am not convinced there is a need to mimic NSH operations 
altogether. But we can sit together this week and discuss.

Tests (including regression tests) are required anyway even in the case you 
mentioned.

DB> Doing testing including regression on software is way less impactful than 
sending technicians to swap out linecards on devices.

Cheers,
Med

De : Bernier, Daniel [mailto:daniel.bern...@bell.ca]
Envoyé : mercredi 21 mars 2018 00:53
À : BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; 
LINGALA, AVINASH; Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian 
Farrel
Cc : mpls; SPRING WG List; b...@ietf.org; s...@ietf.org
Objet : Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


+1 to Jim and Avinash



Same challenge on our side.



Our network is built upon a MPLS data plane. My current "network appliances" 
are connected to MPLS devices and service instantiation done through static 
pseudowires. It will be easier for me to introduce SRTE policy capabilities 
through software upgrades instead of certifying and introducing new hardware to 
enable a newer encap.



And by the time we get to leverage contextual metadata between functions, most 
probably, these will have also evolved (micro-services, hw/sw disaggregation) 
and new ways of conveying that metadata will have been proposed.



Thanks,



PS: I am also wondering why it is so badly seen to look at alternatives to NSH 
SFC while at the same time we introduce new WG to discuss DC routing (RIFT, 
LSVR, ...). If we accept multiplicity in that space, and I think we should, 
then we should allow it in chain composition and programming.



Cheers,



Daniel Bernier




From: mpls <mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>> on behalf of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, 
Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; b...@ietf.org<mailto:b...@ietf.org>; 
s...@ietf.org<mailto:s...@ietf.org>
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

You said that you “simply need SR to realize the chain”, but actually if you 
want a path to be steered relying upon some information conveyed in the packet 
and to invoke specific SFs, then you need to define the structure of such 
information and its meaning.

That is another piece of specification work to be yet done if you want it to be 
part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; 
Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; 
b...@ietf.org<mailto:b...@ietf.org>
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH <ar9...@att.com<mailto:ar9...@att.com>>; BOUCADAIR Mohamed 
IMT/OLN &l

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

[Bernier, Daniel]

+1 to Jim and Avinash


Same challenge on our side.


Our network is built upon a MPLS data plane. My current "network appliances" 
are connected to MPLS devices and service instantiation done through static 
pseudowires. It will be easier for me to introduce SRTE policy capabilities 
through software upgrades instead of certifying and introducing new hardware to 
enable a newer encap.


And by the time we get to leverage contextual metadata between functions, most 
probably, these will have also evolved (micro-services, hw/sw disaggregation) 
and new ways of conveying that metadata will have been proposed.


Thanks,


PS: I am also wondering why it is so badly seen to look at alternatives to NSH 
SFC while at the same time we introduce new WG to discuss DC routing (RIFT, 
LSVR, ...). If we accept multiplicity in that space, and I think we should, 
then we should allow it in chain composition and programming.


Cheers,


Daniel Bernier



From: mpls  on behalf of mohamed.boucad...@orange.com 

Sent: Tuesday, March 20, 2018 7:59 AM
To: UTTARO, JAMES; LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; Henderickx, 
Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; b...@ietf.org; s...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim,

You said that you “simply need SR to realize the chain”, but actually if you 
want a path to be steered relying upon some information conveyed in the packet 
and to invoke specific SFs, then you need to define the structure of such 
information and its meaning.

That is another piece of specification work to be yet done if you want it to be 
part of SR information itself.

Cheers,
Med

De : UTTARO, JAMES [mailto:ju1...@att.com]
Envoyé : mardi 20 mars 2018 11:30
À : LITKOWSKI Stephane OBS/OINIS; LINGALA, AVINASH; BOUCADAIR Mohamed IMT/OLN; 
Henderickx, Wim (Nokia - BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc : mpls; SPRING WG List; s...@ietf.org; b...@ietf.org
Objet : RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear.

The issue as I see it is that I do not require NSH to realize the creation of 
simple chains. I simply need SR to realize the chain. Why is the IETF forcing 
me to adopt technology that I do not need, while at the same time reducing the 
number of vendors that I may use in my network as this encap will have to be 
supported by traditional OEMs and others looking to get into the business.

TBC I am not against NSH it addresses use cases where dynamic complex chains 
are required. The reality of my world is that I have lots of simpler chains i.e 
FW, LB  and do not need the additional OPEX and CAPEX  costs associated with 
deploying NSH.

Jim Uttaro

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, March 20, 2018 6:25 AM
To: LINGALA, AVINASH >; BOUCADAIR Mohamed 
IMT/OLN >; 
UTTARO, JAMES >; Henderickx, Wim (Nokia - 
BE/Antwerp) >; Robert 
Raszuk >; Adrian Farrel 
>
Cc: mpls >; SPRING WG List 
>; s...@ietf.org; 
b...@ietf.org
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN  with various encap options like MPLS, 
> VXLAN, GENEVE,..

Well you do have the same thing with SFC/NSH, you can use any type of transport 
underneath: MPLS, VXLAN, GRE,UDP,…

In your example EVPN provides the service, then you pick the transport you want.
Here SFC/NSH may provide the service (chaining), then you pick also the 
transport you want.


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of LINGALA, AVINASH
Sent: Tuesday, March 20, 2018 10:06
To: BOUCADAIR Mohamed IMT/OLN; UTTARO, JAMES; Henderickx, Wim (Nokia - 
BE/Antwerp); Robert Raszuk; Adrian Farrel
Cc: mpls; SPRING WG List; s...@ietf.org; 
b...@ietf.org
Subject: Re: [mpls] [sfc] Progress with draft-farrel-mpls-sfc


I support this effort and I agree with Jim.  As an operator we would like to 
see various encapsulation options for SFC. This would help an operator to pick 
the suitable encapsulation option for their networks.

Same approach that IETF took for EVPN  with various encap options like MPLS, 
VXLAN, GENEVE,..

​
Thanks,
Avinash Lingala


From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, March 19, 2018 10:25 AM
To: UTTARO, JAMES >; Henderickx, 

Re: [spring] SPRING - rechartering discussion

[Bernier, Daniel]

Hi,

I echo the need to continue the SPRING work on service-chaining. There is a 
growing interest to have a mechanism that operates at the forwarding plane 
level using source routing as an alternative to a dedicated service overlay. 
This will surely generate other related work such as automated service 
discovery, inter-domain chaining policies, parallelism versus sequential 
chaining, various control-plane implementations, etc.

Secondly, since there is a tight relation to SR chaining and TE policies, I 
believe there will is a lot of opportunities related to Path Awareness which is 
currently running in IRTF. Opportunities like, intent translation to SR 
policies, Policy requests or announcements between domains and host (probably 
app) level TE policy requests (e.g. how can an app receive a proper policy 
based on its requirements) ?

My humble operator 0.02 cents.

Daniel Bernier | Bell Canada

From: spring  on behalf of bruno.decra...@orange.com 

Sent: Monday, March 5, 2018 11:59 AM
To: spring@ietf.org
Cc: Alvaro Retana (aretana); spring-cha...@ietf.org
Subject: [spring] SPRING - rechartering discussion

Hello WG,

now that nearly all the core documents are in the hands of IESG or beyond, we 
think it is time to (re)discuss rechartering.
We brought up that question few meetings ago and the feedback, at that  time, 
was that the WG at least needs to be maintained to discuss the extensions 
following deployment feedback.

But we need also identify technical directions.

In order to initiate the discussion we are proposing some high level items but 
we'd like to make clear a few points before:
 * these are only proposals; what might end-up as the next steps for SPRING 
will be what the WG is willing to work on (which includes having cycles for 
that).
 * what the WG might be rechartered to do is not necessarily limited to that; 
so other proposals are welcome.

 So, we thought of the following:

 * general architectural work / extensions
 there are still few items on our plate and we expect that some might need to 
be progressed, and we should maybe allow for others to come.

 * service chaining
 last meeting there were proposals discussed in SPRING to realize some form of 
service chaining. any work in that space would require close coordination with 
SFC and maybe other WG.

 * yang
 we are a bit behind here and there is definitely work to do.


So please comment on these and propose additional items.

We'll likely have a dedicated slot in London but we'd like to progress before 
that.

Thank you,
--Martin, Rob, Bruno

 > -Original Message-
 > From: Martin Vigoureux [mailto:martin.vigour...@nokia.com]
 > Sent: Wednesday, March 29, 2017 4:25 PM
 > To: spring@ietf.org
 > Cc: spring-cha...@ietf.org; Alvaro Retana (aretana)
 > Subject: Next steps for SPRING?
 >
 > WG,
 >
 > in the session we have opened the discussion on the future of the WG,
 > putting all options on the table (recharter/close/sleep).
 > As a foreword, we still have few WG Documents that we need to -and will-
 > push towards IESG (and a greater number that need to reach RFC status),
 > but with those we'll have reached most if not all of our milestones,
 > thus the question on what's next.
 >
 > So, we think we have heard during the session that closing wasn't
 > desired and one reason for that is to have a home to share and discuss
 > deployment considerations as the technology gets deployed.
 > There are also a few individual documents knocking at the door, and some
 > of them were presented during the session.
 >
 > To reach out to everyone, we are thus asking the question on the list.
 > We would like to hear from you all what the working group should be
 > focussing on.
 >
 > Note, the expectation is that future items should not be use-cases but
 > rather be technology extensions/evolutions.
 >
 > Thank you
 >
 > Martin & Bruno

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: [spring] [mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Bernier, Daniel]

e similar to SFC but the solutions 
might differ.
 
The IANA considerations sections give a good indication of where the drafts 
belong. draft-xuclad-spring-sr-service-chaining asks for allocations from the 
"Segment-routing with IPv6 dataplane (SRv6)
 Parameters"  registry: that registry has not been created yet, but is 
probably intended to be the registry discussed in 
draft-filsfils-spring-srv6-network-programming so the discussion would belong 
in SPRING. draft-farrel-mpls-sfc asks for allocations the
 "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" 
registry and that means it should be discussed in the MPLS WG.
 
In summary, when draft-xuclad-spring-sr-service-chaining references 
draft-farrel-mpls-sfc it says "This label stacking  (i.e., the SR approach 
described in draft-xuclad) is completely different from
 other proposals such as [RFC8300] and the MPLS label swapping mechanism 
described in [I-D.farrel-mpls-sfc]."
 
I agree with that statement and think each draft should progress at its own 
speed and in its own appropriate WG.

DB> Agreed on the WG placement and parallel progress if the community sees 
interest in pursuing multiple approaches to RFC7665 SPI/SI encoding 
(https://mailarchive.ietf.org/arch/msg/spring/7DjGQpbTeRZj1gLtxOcjbF4Rybc) . I 
just do not see the need to detail section 6 other than to reference 
draft-filsfils-spring-segment-routing-mpls if you want to use MPLS-SR instead 
of label swapping for the transport tunnels since the meat of 
draft-farrel-mpls-sfc is in the use of 2 labels (+entropy) to represent the 
SPI/SI. 

DB> I personally thing draft-xuclad-spring-sr-service-chaining should progress 
since it is defining ways to define a chain not as a transport agnostic overlay 
but integrated within the forwarding plane described as a TE policy.

    Yours Irrespectively,
 
John

 
From: Bernier, Daniel [mailto:daniel.bern...@bell.ca]

Sent: Friday, March 9, 2018 12:15 AM
To: Kamran Raza (skraza) <skr...@cisco.com>; Zafar Ali (zali) 
<z...@cisco.com>; Francois Clad (fclad) <fc...@cisco.com>;
徐小虎(义先) <xiaohu@alibaba-inc.com>
Cc: mpls <m...@ietf.org>; SPRING WG List <spring@ietf.org>; s...@ietf.org; 
draft-farrel-mpls-sfc <draft-farrel-mpls-...@ietf.org>; mpls-chairs 
<mpls-cha...@ietf.org>; mpls <mpls-boun...@ietf.org>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"


 
​Hi,
 
As co-author of both initial draft-xu-mpls-service-chaining, 
draft-clad-spring-segment-routing-service-chaining and the merged 
draft-xuclad-spring-sr-service-chaining, I
 also have concerns about the current WG adoption process and haste.  I do 
hope we will be in a position to discuss in London, which is merely days away.
 
Thanks,
 
Daniel Bernier | Bell Canada​


From: mpls <mpls-boun...@ietf.org> on behalf of Kamran Raza (skraza) 
<skr...@cisco.com>
Sent: Thursday, March 8, 2018 11:43 PM
To: Zafar Ali (zali); Francois Clad (fclad); 徐小虎(义先)
Cc: mpls; SPRING WG List; s...@ietf.org; draft-farrel-mpls-sfc; 
mpls-chairs; mpls
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"
 


I second the concerns raised by Xiaohu, Francois, and Zafar.

 
From: mpls <mpls-boun...@ietf.org> on behalf of "Zafar Ali (zali)" 
<z...@cisco.com>
Date: Thursday, March 8, 2018 at 7:02 PM
To: "Francois Clad (fclad)" <fc...@cisco.com>, "徐小虎(义先)"
 <xiaohu@alibaba-inc.com>
Cc: mpls <m...@ietf.org>, SPRING WG List <spring@ietf.org>, "s...@ietf.org" 
<s...@ietf.org>, draft-farrel-mpls-sfc
 <draft-farrel-mpls-...@ietf.org>, mpls-chairs <mpls-cha...@ietf.org>, mpls 
<mpls-boun...@ietf.org>
Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

 

Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc,

 
I would like to draw your attention to the serious issue raised by Xiaohu 
and Francois.

 
Summary:
 
Please note that this working group adaption against the IETF process and 
its spirit. Please recall the adaption call.

 
Details:

 
Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we 
discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc 
and draft-clad-spring-segment-routing-service-chaining)
 in SFC, Spring and MPLS WG. There was the specific conversation on which 
WG the work belongs, and the assumed follow-up 

Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued"

[Bernier, Daniel]

Hi John,


Don't we already have 
draft-fm-bess-service-chaining-01
 to perform service chains with existing MPLS implementations ?


Thanks,​


Daniel Bernier


From: spring  on behalf of John E Drake 

Sent: Wednesday, March 14, 2018 8:51 AM
To: Robert Raszuk
Cc: mpls; SPRING WG List; s...@ietf.org; James N Guichard; adr...@olddog.co.uk; 
Francois Clad (fclad)
Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Robert,

The point is to re-purpose existing MPLS hardware in the short-term to build 
service function forwarders.

Yours Irrespectively,

John

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:52 PM
To: John E Drake 
Cc: James N Guichard ; Francois Clad (fclad) 
; adr...@olddog.co.uk; mpls ; SPRING WG List 
; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

However, early adopters were concerned about the availability of hardware NSH 
implementations and asked us to include the option of using an MPLS label stack 
to carry the [SPI, SI], which we did.

Are you saying that there is more service function hardware out there in the 
market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so 
and if you or someone will list and compare both I am game to progress this 
work - no issue. If not I really do not see much point.

So far I have seen zero of the former and quite a bit of the latter hence my 
post.

Yours,
Robert.



On Tue, Mar 13, 2018 at 10:44 PM, John E Drake 
> wrote:
Robert,

Comments inline.

Yours Irrespectively,

John

From: rras...@gmail.com 
[mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, March 13, 2018 5:13 PM
To: John E Drake >
Cc: James N Guichard 
>; Francois 
Clad (fclad) >; 
adr...@olddog.co.uk; mpls 
>; SPRING WG List 
>; s...@ietf.org
Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc 
in state "Call For Adoption By WG Issued"

Hi John,

There is one point which I am missing in this discussion ... why we are over 
and over duplicating ways to solve the same problem. Is there some sort of 
starvation of the problems to be solved ? Or is there an issue of "technology 
not invented here must be bad" ?

[JD]  ‘BGP Control Plane for NSH SFC ‘ ( 
https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02),
 the control plane companion to the subject draft is, as its title indicates, 
designed to work using the NSH.  However, early adopters were concerned about 
the availability of hardware NSH implementations and asked us to include the 
option of using an MPLS label stack to carry the [SPI, SI], which we did.

You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to 
handle situations in which the NSH is not ubiquitously deployed." What are 
those situations considering that MPLS requires IP both control plane and 
forwarding to be in place so does NSH.

[JD]  See above

Would now all of the v-service vendors need to support both ways of encoding 
service/function IDs ?

[JD]  I would expect a graceful transition, i.e., one SFF at a time, from MPLS 
label stack to NSH, and the control plane draft explicitly includes the 
infrastructure necessary to allow both to be included, on a hop by hop basis, 
in the same service function path (the instantiation of a service function 
chain.)

Isn't this waist of everyone's time and effort ?

[JD]  See above

Last - how does  draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh 
maybe there is and not going to be such thing ?

[JD]  Like a charm.  The underlay would be IPv6, perhaps w/ SR, and the overlay 
would be NSH.  We use the Encapsulation attribute to completely decouple the 
overlay and underlay networks.

 Best,
Robert.


On Tue, Mar 13, 2018 at 9:59 PM, John E Drake 
> wrote:
Jim,

Excellent point.  We thought a context label was crucial in order 

Re: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

[Bernier, Daniel]

Hi Jeff, 

Sorry about the confusion.

Personally, I would like to have it in a standard track so we end-up with a 
reference implementation that everyone can fall back to and ensure consistency 
and interoperability. Much like was being done with 
https://tools.ietf.org/html/draft-ietf-bess-service-chaining-03.
There will always be options to diverge and build custom implementations but 
with a referenced standard, it makes it easier for us.

Hope that's clearer

Thanks,

Daniel Bernier


From: Jeff Tantsura <jefftant.i...@gmail.com>
Sent: Tuesday, October 24, 2017 1:40 PM
To: Bernier, Daniel; Francois Clad (fclad); spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for 
draft-clad-spring-segment-routing-service-chaining-00.txt

Hi Daniel,

Thank you for taking the microphone.
Perhaps my question wasn’t clear – I’m completely with you on the need of SFC 
SR properly documented, however the way document reads – it defines number of 
behaviors/functions and provides some ideas how those could be implemented. 
Hence my question, whether you think Informational track would be more 
appropriate.

Thanks!

Cheers,
Jeff

-Original Message-
From: "Bernier, Daniel" <daniel.bern...@bell.ca>
Date: Tuesday, October 24, 2017 at 09:35
To: Jeff Tantsura <jefftant.i...@gmail.com>, "Francois Clad (fclad)" 
<fc...@cisco.com>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: [spring] FW: New Version Notification for 
draft-clad-spring-segment-routing-service-chaining-00.txt

Hi Jeff,

Do you mind if I take the microphone on this one?

The expired draft-homma (ref: 
https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-05#page-23
 ) on SFC forwarding methods detailed pretty well the various options for 
forwarding in the context of service chaining and in particular the value for 
SPs into the use of stacked headers but also potential caveats or required 
enhancements at the time of writing.

Following on that thought, I think it becomes essential that SPRING 
addresses these caveats/enhancements.

And contrary to Alvaro’s comment in his review of 
draft-ietf-spring-segment-routing-mpls (ref: 
https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8/?qid=75cfe3b3b0f6d44817785cc576610ac3
 ). I believe it also becomes apparent that answering SFC is “vital”. As it was 
part of the SR architecture drafts from the beginning (ref:  
https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-23 ). 
Even more reason to address this in SPRING.

So, going back to your question, for us operators, I think it is essential 
that required forwarding behaviors, such as proxy mechanisms leveraging SR, get 
standardized so we can get interoperability and predictability between 
implementations. Be it in software or hardware.

For an SP, the notion of “service-chains” is currently pretty hard to 
deploy and troubleshoot even more so in a multi-vendor fashion, it would be 
even harder if behaviors like proxies, behave differently.

Hope it makes sense

Thanks,

--
Daniel Bernier


From: spring <spring-boun...@ietf.org> on behalf of Jeff Tantsura 
<jefftant.i...@gmail.com>
Sent: Wednesday, October 18, 2017 4:34 PM
To: Francois Clad (fclad); spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for 
draft-clad-spring-segment-routing-service-chaining-00.txt

Hi Francois,

The draft has been published as the Standards Track document.
What is it you have been trying to standardize?

Thanks!

Cheers,
Jeff

-Original Message-
From: spring <spring-boun...@ietf.org> on behalf of "Francois Clad (fclad)" 
<fc...@cisco.com>
Date: Wednesday, October 18, 2017 at 07:46
To: "spring@ietf.org" <spring@ietf.org>
Subject: [spring] FW: New Version Notification for 
draft-clad-spring-segment-routing-service-chaining-00.txt

Hello,

We have just submitted 
draft-clad-spring-segment-routing-service-chaining-00.

Any feedback is welcome.

Regards,
Francois

On 06/10/2017, 21:32, "internet-dra...@ietf.org" 
<internet-dra...@ietf.org> wrote:


A new version of I-D, 
draft-clad-spring-segment-routing-service-chaining-00.txt
has been successfully submitted by Francois Clad and posted to the
IETF repository.

Name:   draft-clad-spring-segment-routing-service-chaining
Revision:   00
Title:  Segment Routing for Service Chaining
Document date:  2017-10-06
Group:  Individual Submission
Pages:  24
URL:
https://www.ietf.org/internet-drafts/draft-clad-spring-s

Re: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

[Bernier, Daniel]

Hi Jeff, 

Do you mind if I take the microphone on this one?

The expired draft-homma (ref: 
https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-05#page-23
 ) on SFC forwarding methods detailed pretty well the various options for 
forwarding in the context of service chaining and in particular the value for 
SPs into the use of stacked headers but also potential caveats or required 
enhancements at the time of writing.  

Following on that thought, I think it becomes essential that SPRING addresses 
these caveats/enhancements. 

And contrary to Alvaro’s comment in his review of 
draft-ietf-spring-segment-routing-mpls (ref: 
https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8/?qid=75cfe3b3b0f6d44817785cc576610ac3
 ). I believe it also becomes apparent that answering SFC is “vital”. As it was 
part of the SR architecture drafts from the beginning (ref:  
https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-23 ). 
Even more reason to address this in SPRING.

So, going back to your question, for us operators, I think it is essential that 
required forwarding behaviors, such as proxy mechanisms leveraging SR, get 
standardized so we can get interoperability and predictability between 
implementations. Be it in software or hardware. 

For an SP, the notion of “service-chains” is currently pretty hard to deploy 
and troubleshoot even more so in a multi-vendor fashion, it would be even 
harder if behaviors like proxies, behave differently.

Hope it makes sense

Thanks,

--
Daniel Bernier


From: spring  on behalf of Jeff Tantsura 

Sent: Wednesday, October 18, 2017 4:34 PM
To: Francois Clad (fclad); spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for 
draft-clad-spring-segment-routing-service-chaining-00.txt

Hi Francois,

The draft has been published as the Standards Track document.
What is it you have been trying to standardize?

Thanks!

Cheers,
Jeff

-Original Message-
From: spring  on behalf of "Francois Clad (fclad)" 

Date: Wednesday, October 18, 2017 at 07:46
To: "spring@ietf.org" 
Subject: [spring] FW: New Version Notification for 
draft-clad-spring-segment-routing-service-chaining-00.txt

Hello,

We have just submitted 
draft-clad-spring-segment-routing-service-chaining-00.

Any feedback is welcome.

Regards,
Francois

On 06/10/2017, 21:32, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, 
draft-clad-spring-segment-routing-service-chaining-00.txt
has been successfully submitted by Francois Clad and posted to the
IETF repository.

Name:   draft-clad-spring-segment-routing-service-chaining
Revision:   00
Title:  Segment Routing for Service Chaining
Document date:  2017-10-06
Group:  Individual Submission
Pages:  24
URL:
https://www.ietf.org/internet-drafts/draft-clad-spring-segment-routing-service-chaining-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-clad-spring-segment-routing-service-chaining/
Htmlized:   
https://tools.ietf.org/html/draft-clad-spring-segment-routing-service-chaining-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-clad-spring-segment-routing-service-chaining-00


Abstract:
   This document defines data plane functionality required to implement
   service segments and achieve service chaining with MPLS and IPv6, as
   described in the Segment Routing architecture.




Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring