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

[Takuya Miyasaka]

Hi,

I support the adoption of this draft.

While SRv6 has high potential, for a simple operation such as TE the 
high packet length overhead of SRv6 has been an issue for operators. 
This draft resolves this issue and  (I believe) a necessary feature for 
operators, so we would like to support this draft.


Thanks,
Takuya

On 2021/10/01 23:04, James Guichard wrote:


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 15^th 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


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

Re: [spring] Progressing Standardizing SR over IPv6 compression

[Takuya Miyasaka]

Hi,

Firstly, I would like to thank the design team for their outstanding work.

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

Yes.

From the operator's point of view, we are always looking for quick 
implementation and interoperability across multiple vendors. For this 
reason, we prefer one data plane under the SRv6 umbrella.


Regards,
Takuya

On 2021/08/05 3:52, 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


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

Re: [spring] Completion of WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Takuya Miyasaka]

Hi,

I am not aware of any IPRs related to this document.

Regards,
Takuya

On 2021/02/12 2:06, James Guichard wrote:


Dear WG:

This email ends the 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
. 



Having reviewed all of the responses, the chairs believe that enough 
support was received to adopt this document into the WG. However, 
while the document is informational in nature, it does have a 
normative dependency on 
https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/ 
 
which will need to successfully complete WG LC before this document 
will be able to progress from the WG queue. The chairs feel that more 
work is necessary in terms of definition and interoperability of 
resource-aware SIDs. In addition several comments were received during 
the adoption call that will need to be addressed as the document 
progresses through the WG process. Further, the chairs would like to 
make it clear that adopting an informational document that proposes a 
particular solution which utilizes resource-aware SIDs does **not** 
preclude future adoption of other documents which propose a different 
solution if the trade-offs are significantly different.


Authors, please resubmit the document as 
draft-spring-sr-for-enhanced-vpn-00 and also provide explicit 
confirmation as to whether you are aware of any IPR related to this 
document.


Regards,

Jim, Joel & Bruno

*From:* James Guichard 
*Sent:* Wednesday, January 27, 2021 5:47 AM
*To:* spring@ietf.org
*Cc:* spring-cha...@ietf.org
*Subject:* WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
 
ending February 10^th 2021.


After review of the document please indicate support (or not) for WG 
adoption to the mailing list and if you are willing to work on the 
document, please state this explicitly. This gives the chairs an 
indication of the energy level of people in the working group willing 
to work on this document. 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.


Thanks!

Jim, Bruno & Joel


___
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] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-02.txt

[Takuya Miyasaka]

Hi Ron,

Thank you for the quick update and I confirmed that my comments are 
incorporated in this version.


Thanks,
Takuya

On 2021/02/10 6:04, Ron Bonica wrote:

Folks,

The draft has been updated to reflect Takuya's and Jeff's comments.

Ron


Juniper Business Use Only


-Original Message-
From: internet-dra...@ietf.org 
Sent: Tuesday, February 9, 2021 3:59 PM
To: Greg Mirsky ; Peng Shaofu
; Ron Bonica ; Shaofu Peng
; Shraddha Hegde ; EXT-
zhang.zh...@zte.com.cn 
Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-02.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-spring-srv6-end-dtm-02.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name:   draft-bonica-spring-srv6-end-dtm
Revision:   02
Title:  The SRv6 END.DTM Endpoint Behavior
Document date:  2021-02-09
Group:  Individual Submission
Pages:  7
URL: https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-02.txt
Status: https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm
Htmlized:  
https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm
Htmlized:   https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-02
Diff: https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-02

Abstract:

This document describes a new SRv6 endpoint behavior, called END.DTM.
The END.DTM endpoint behavior supports inter-working between SRv6 and
SR-MPLS.  Like any endpoint behavior, END.DTM contains a function and
arguments.  The function causes the processing SRv6 node to remove an
SRv6 header, impose an SR-MPLS label stack, and forward the packet to
its next hop.  The arguments determine MPLS-label stack contents and
the next hop.




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

Re: [spring] FW: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[Takuya Miyasaka]

Hi Ron,

I think this new SRv6 endpoint behavior is very useful to connect an 
SRv6 island and an SR-MPLS island. I have two comments.


In this draft, you introduced the End.DTM as a new "segment type", but 
according to draft-ietf-spring-srv6-network-programming draft I think 
this should be "endpoint behavior".


Section.1 says "The arguments determine MPLS-label stack contents and 
Transport Class of the MPLS Tunnel." I was interested in this feature, 
but there is no detailed description in Section.4. Could you elaborate 
on this feature in the future version? I also want to clarify the 
meaning of "Transport Class of the MPLS Tunnel".


Thanks,
Takuya

On 2021/02/08 1:46, Ron Bonica wrote:

Please review and comment


Juniper Business Use Only


-Original Message-
From: internet-dra...@ietf.org 
Sent: Sunday, February 7, 2021 11:41 AM
To: Greg Mirsky ; Peng Shaofu
; Ron Bonica ; Shaofu Peng
; Shraddha Hegde ; EXT-
zhang.zh...@zte.com.cn 
Subject: New Version Notification for draft-bonica-spring-srv6-end-dtm-01.txt

[External Email. Be cautious of content]


A new version of I-D, draft-bonica-spring-srv6-end-dtm-01.txt
has been successfully submitted by Ron Bonica and posted to the IETF
repository.

Name:   draft-bonica-spring-srv6-end-dtm
Revision:   01
Title:  The SRv6 END.DTM Segment Type
Document date:  2021-02-07
Group:  Individual Submission
Pages:  7
URL:   https://www.ietf.org/archive/id/draft-bonica-spring-srv6-end-dtm-01.txt
Status: https://datatracker.ietf.org/doc/draft-bonica-spring-srv6-end-dtm
Htmlized:  
https://datatracker.ietf.org/doc/html/draft-bonica-spring-srv6-end-dtm
Htmlized:  https://tools.ietf.org/html/draft-bonica-spring-srv6-end-dtm-01
Diff:  https://www.ietf.org/rfcdiff?url2=draft-bonica-spring-srv6-end-dtm-01

Abstract:
This document describes a new SRv6 segment type, called END.DTM.  The
END.DTM segment type supports inter-working between SRv6 and SR-MPLS.
Like any segment type, END.DTM contains a function and arguments.
The function causes the processing SRv6 node to remove an SRv6 header
and impose an SR-MPLS label stack.  The arguments determine MPLS-
label stack contents.




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

Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Takuya Miyasaka]

Hi WG,

I support the adoption of this draft as a coauthor.

Some of our customers have already asked us to provide resource isolated 
networks for their mission-critical applications such as real-time video 
transfer, remote surgery, remote control vehicle. To realize such a 
request, I think this draft and resource-aware SID is useful.


Thanks,
Takuya

On 2021/01/27 20:46, James Guichard wrote:


Dear WG:

This message starts a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
 
ending February 10^th 2021.


After review of the document please indicate support (or not) for WG 
adoption to the mailing list and if you are willing to work on the 
document, please state this explicitly. This gives the chairs an 
indication of the energy level of people in the working group willing 
to work on this document. 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.


Thanks!

Jim, Bruno & Joel


___
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] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

[Takuya Miyasaka]

AS a coauthor, I support this adoption. From an operator perspective, 
the idea brought by this draft is useful for the efficient resource 
reservation.


Thanks,
Takuya


Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ 
ending Wednesday 29^th July 2020.


Please speak up if you support or oppose adopting this document into 
the WG. Please also provide comments/reasons for that support (or lack 
thereof). Silence will not be considered consent.


Thanks!

Jim, Joel & Bruno


___
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] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

[Takuya Miyasaka]

Hi Sasha and Jie,

As for the document type (standard track or informational),  my personal 
opinion is that if we need to assign a new IANA code-point on this new 
SR resource semantics at another draft, this document will be Standards 
Track (as an example, a new IS-IS sub-TLVs (RFC8667) for the resource SID).


Regards,
Takuya

On 2020/05/25 23:37, Dongjie (Jimmy) wrote:


Hi Sasha,

Thanks a lot for your comments. Please see some replies inline.

Best regards,

Jie

*From:*Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com]
*Sent:* Monday, May 25, 2020 8:12 PM
*To:* Mach Chen 
*Cc:* draft-dong-spring-sr-for-enhanced-...@ietf.org; Joel M. Halpern 
; Dongjie (Jimmy) ; 
qinfengwei ; 'SPRING WG' 
*Subject:* RE: [spring] 答复: Progressing 
draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource 
management


Mach and all,

From my POV saying that " With current SR ... there is no way for the 
devices to differentiate traffic over the same link or to the same 
destination, because the SID used by all the flows are the same" is 
inaccurate.


[Jie] Agree that the condition of this statement could be more 
accurate, to my understanding it was referring to the basic SR 
functionality.


AFAIK it is perfectly possible to associate multiple Prefix-SIDs with 
the same */destination/* */prefix/* by associating them either with 
different topologies or with different algorithms (or even with a 
combination of these two parameters).


It is also possible to associate multiple Adj-SIDs (if you want to use 
them) with the same IGP adjacency by associating them with different 
topologies (but not with different algorithms).


[Jie] You are right that with MT or Flex-Algo, multiple prefix-SIDs 
can be associated with the same destination prefix , and with MT you 
can also have topology-specific adj-SIDs. This is also the reason of 
reusing MT/Flex-Algo as the corresponding control plane mechanisms.


Therefore it seems that the following recommendations from Section 2.1 
of the draft are adequately addressed by the already defined SR-MPLS 
mechanisms:


   For one IGP link, multiple Adj-SIDs SHOULD be allocated, each of

   which is associated with a virtual network it participates, and MAY

   represent a subset of link resources

...

   Similarly, for one IGP node, multiple prefix-SIDs SHOULD be
   allocated, each of which is associated with a virtual network , and
   MAY represent a subset of the node resource
[Jie] You may notice that in the above statement, each adj-SID or 
prefix-SID can be associated with a subset of the link or node 
resource. This is the resource semantics introduced to the SR SIDs by 
this document.
There may be valid reasons not to use these mechanisms for associating 
multiple SIDs with a given destination prefix or an IGP adjacency, but 
the draft does not mention any such reasons.
[Jie] As mentioned above, I totally agree with reusing existing 
control plane mechanisms to advertise multiple topology or algorithm 
specific SIDs, these are the approach we choose for the control plane, 
the detailed mechanism was proposed in LSR WG.
This SPRING draft is focusing on introducing resource semantics to 
SIDs, which is more related to the SR data plane and functionality. 
Another point is, based on the mechanism defined in this draft, it is 
also possible to build resource guaranteed SR paths, without 
introducing the concept of MT or Flex-Algo.


I defer to others to decide whether existing SRv6 mechanisms are 
sufficient for addressing similar requirements in Section 2.2 of the 
draft.


I also wonder whether draft-dong is a valid candidate for the 
Standards Track document since it does not define any specific 
protocol elements.  My gut feeling is that it could be a better fit 
for an Informational document.


[Jie] I’m open to this standard track or informational discussion. As 
long as the functionality and information introduced in this document 
is considered useful to SR.


Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

Email: alexander.vainsht...@ecitele.com 



-Original Message-
From: spring > On Behalf Of Mach Chen

Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern >; Dongjie (Jimmy) >; qinfengwei >; 'SPRING WG' >
Cc: draft-dong-spring-sr-for-enhanced-...@ietf.org 

Subject: Re: [spring] 答复: Progressing 
draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource 
management


Hi,

Is the "resource allocation" performed only on the controller? If so, 
sounds like a virtual resource reservation, or somehow it is more 
accurate to call it resource planning. In this case, the 
interoperability issues may not be the most concerns. The problem is 
how to guarantee the resource reservation on the 

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

[Takuya Miyasaka]

I support the adoption of this draft. This kind of feature is very 
useful from operator's point of view.


Thanks,
Takuya

On 2018/05/17 0:20, Rob Shakir 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


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