[spring] Re: 答复: spring WG Adoption Call for draft-peng-spring-pmtu-sr-policy

[Linda Dunbar]

I support the WG adoption of this draft with the following comments:

- IPv6 packets can't be fragmented by intermediate routers. Meaning SR ingress 
routers can't fragment the packet even if SR-MTU is above the limit.  Suggest 
adding more description in Section 5.4 (Handling behaviors on the headend) when 
SR-MTU does exceed the limit. Does the headend node have option of selecting a 
subset of SIDs if the SR-MTU is exceeding the limit? Or not adding SIDs at all? 
 Or sending ICMPv6 message back to the hosts?

- As the end hosts relies on Path MTU Discovery to determine the MTU, maybe the 
SR ingress nodes need to use the longest possible SR header for Path MTU 
Discovery packets? So that the original hosts can reduce the packet size no 
matter which SR path is taken.

Thanks, Linda Dunbar


-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Alvaro Retana
发送时间: 2024年6月18日 23:42
收件人: SPRING WG 
抄送: draft-peng-spring-pmtu-sr-pol...@ietf.org; spring Chairs 

主题: [spring] spring WG Adoption Call for draft-peng-spring-pmtu-sr-policy

Dear WG:

This message starts a two-week adoption call for 
draft-peng-spring-pmtu-sr-policy, ending on July/2nd. From the
Abstract:

   This document defines the Path MTU (PMTU) for Segment Routing (SR)
   Policy (called SR-PMTU). It applies to both Segment Routing over IPv6
   (SRv6) and SR-MPLS. This document specifies the framework of SR-PMTU
   for SR Policy including the link MTU collection, the SR-PMTU
   computation, the SR-PMTU enforcement, and the handling behaviours on
   the headend.


   https://datatracker.ietf.org/doc/draft-peng-spring-pmtu-sr-policy/


Please review the draft and consider whether you support its adoption by the 
WG. Please share any thoughts with the list to indicate support or opposition 
-- this is not a vote.

If you are willing to provide a more in-depth review, please state it 
explicitly to give the chairs an indication of the energy level in the working 
group willing to work on the document.

WG adoption is the start of the process. The fundamental question is whether 
you agree the proposal is worth the WG's time to work on and whether this draft 
represents a good starting point. The chairs are particularly interested in 
hearing the opinions of people who are not authors of the document.

Note that draft-ietf-pce-pcep-pmtu ("Support for Path MTU (PMTU) in the Path 
Computation Element (PCE) Communication Protocol (PCEP)") Normatively 
references this document. It may be helpful to look at that document too.

Thanks!

Alvaro (for the Chairs)

___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org 
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Re: [spring] Review comments and questions to draft-ietf-spring-srv6-srh-compression-08

[Linda Dunbar]

Francois,

Thank you very much for the explanation. Your amended text looks good to me.

Thank you,

Linda

From: Francois Clad 
Sent: Wednesday, October 25, 2023 9:21 AM
To: Linda Dunbar 
Cc: spring@ietf.org; draft-ietf-spring-srv6-srh-compress...@ietf.org
Subject: Re: Review comments and questions to 
draft-ietf-spring-srv6-srh-compression-08

Dear Linda,

Thank you for your review of this document. Your feedback is much appreciated.

We have clarified and amended the text in response to your review, and these 
modifications were included as part of the recently submitted revision 9 
(https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/9/).

Please also see inline below ([FC]) specific replies to your comments and 
questions.

Thanks,
Francois (and behalf of the C-SID co-authors)


On Sep 15, 2023 at 20:39:08, Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Weiqiang, clarence, Zhenbin, Bruno, and Francois,

Reading through the draft-ietf-spring-srv6-srh-compression-08 for the first 
time without prior engagement in the discussion, I think the document is well 
written and clear. Here are some comments and questions:

Section 7.2 helps me the most in comprehending the mechanism described in the 
draft. It would be nice if adding a reference in Section 3 (Basic Concepts) to 
inform readers of the pseudo-code of the SR source node compressing the SID.

[FC] We added a reference to the source node and segment endpoint sections in 
section 3.

  The compressed encoding is achieved by combining a compressed segment
  list encoding logic on the SR source node (Section 6) with new
  flavors of the base SRv6 segment endpoint behaviors that decode this
  compressed encoding (Section 4).


Section 6.4 (Recommended Installation of C-SIDs in FIB):  The first sentence 
states that an SR segment endpoint node SHOULD install the corresponding FIB 
entry to match only the locator and function parts of SIDs. It is not clear who 
is responsible for installing the FIB entry? Is it by IGP? BGP or manual 
configuration?

[FC] This would be an implementation decision and may vary based on the SID 
type. Similar to RFC 8754 and RFC 8986, this document is only concerned that 
the SR segment endpoint node installs a FIB entry for each of its local SIDs.

>From RFC 8754:

4.3. SR Segment Endpoint Node

  Without constraining the details of an implementation, the SR
  segment endpoint node creates Forwarding Information Base (FIB)
  entries for its local SIDs.

  When an SRv6-capable node receives an IPv6 packet, it performs a
  longest-prefix-match lookup on the packet's destination address.
  This lookup can return any of the following:

  - A FIB entry that represents a locally instantiated SRv6 SID
  - A FIB entry that represents a local interface, not locally
instantiated as an SRv6 SID
  - A FIB entry that represents a nonlocal route
  - No Match


There are many acronyms, LBL, LNL, FL, LNFL, etc., used in the document. Can 
you list all of them in the Terminology section?

[FC] We added the missing acronyms in section 2.

  In this document, the length of each constituent part of a SID is
  referred to as follows.

  - LBL is the Locator-Block length of the SID.
  - LNL is the Locator-Node length of the SID.
  - FL is the Function length of the SID.
  - AL is the Argument length of the SID.

  In addition, LNFL is the sum of the Locator-Node length and the
  Function length of the SID. It is also referred to as the C-SID
  length.



Section 4.1.3: the pseudo code has "Set the packet's associated FIB table to 
T". I see it is also described in the RFC8986 for multi-table operation in the 
core. Can you elaborate what scenarios will a node have multi-table for IPv6 
forwarding?

[FC] Section 4.1.3 (and 4.2.3) define the C-SID flavors for the End.T behavior 
of RFC 8986. The operators who are relying on the End.T SIDs of RFC 8986 for 
multi-table operation may find it useful that these SIDs be compressible.


Section 5.1: states that "a Global C-SID typically identifies a shortest path 
to a node in the SRv6 domain".  Earlier sections describe Global SID is a group 
of SID in the SRv6 domain. Isn't "shortest Path" computed based on IGP 
advertisement? Why Global C-SID?

[FC] We clarified the definition of global (and local) C-SIDs in section 5. 
Please let us know if the new text answers your questions.

5.1. Global C-SID

  A global C-SID is a C-SID allocated from the GIB.

  A global C-SID identifies a segment defined at the Locator-Block
  level. The tuple (Locator-Block, C-SID) identifies the same segment
  across all nodes of the SR domain. A typical example is a prefix
  segment bound to the End behavior.

  A node can have multiple global C-SIDs under the same Locator-Block
  (e.g., one per IGP flexible algorithm ([RFC9350])). Multiple nodes
  may share the same global C-SID (e.g., anycast).




Thank you,
Linda




  *
_

[spring] Review comments and questions to draft-ietf-spring-srv6-srh-compression-08

[Linda Dunbar]

Weiqiang, clarence, Zhenbin, Bruno, and Francois,

Reading through the draft-ietf-spring-srv6-srh-compression-08 for the first 
time without prior engagement in the discussion, I think the document is well 
written and clear. Here are some comments and questions:

Section 7.2 helps me the most in comprehending the mechanism described in the 
draft. It would be nice if adding a reference in Section 3 (Basic Concepts) to 
inform readers of the pseudo-code of the SR source node compressing the SID.

Section 6.4 (Recommended Installation of C-SIDs in FIB):  The first sentence 
states that an SR segment endpoint node SHOULD install the corresponding FIB 
entry to match only the locator and function parts of SIDs. It is not clear who 
is responsible for installing the FIB entry? Is it by IGP? BGP or manual 
configuration?

There are many acronyms, LBL, LNL, FL, LNFL, etc., used in the document. Can 
you list all of them in the Terminology section?

Section 4.1.3: the pseudo code has "Set the packet's associated FIB table to 
T". I see it is also described in the RFC8986 for multi-table operation in the 
core. Can you elaborate what scenarios will a node have multi-table for IPv6 
forwarding?

Section 5.1: states that "a Global C-SID typically identifies a shortest path 
to a node in the SRv6 domain".  Earlier sections describe Global SID is a group 
of SID in the SRv6 domain. Isn't "shortest Path" computed based on IGP 
advertisement? Why Global C-SID?


Thank you,
Linda




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

Re: [spring] Volunteers for the SPRING SRv6 Compression draft

[Linda Dunbar]

Joel,

I would be interested, especially your first task: interested in SRv6 and 
compression but has not been involved in implementation nor reading the draft 
repeatedly.

Linda

-Original Message-
From: spring  On Behalf Of Joel Halpern
Sent: Wednesday, September 6, 2023 11:11 AM
To: SPRING WG List 
Subject: [spring] Volunteers for the SPRING SRv6 Compression draft

While we await further discussion between commentors and editors (and the WG as 
a whole) on draft-ietf-spring-srv6-srh-compression, I am looking for at least 
two volunteers (more are welcome).

One volunteer is for a slightly unusual ask.  I am looking for someone who is 
interested in SRv6 and compression, but has not been involved in implementation 
nor reading the draft repeatedly. I would like that person to perform a 
thorough review, with a particular eye towards whether the text is sufficiently 
clear for folks who have not lived through this.

I am also looking for someone to serve as document shepherd for this document.  
While I have (with Alvaro) been handling it as chair, it would be good to have 
a WG member who is interested in the topic and interested in being more 
involved in IETF processes serve as document shepherd.

For both roles, please contact me or the wpring-cha...@ietf.org alias.

Thank you,

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

[spring] Genart last call review of draft-ietf-spring-nsh-sr-11

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-spring-nsh-sr-??
Reviewer: Linda Dunbar
Review Date: 2022-06-30
IETF LC End Date: 2022-06-30
IESG Telechat date: Not scheduled for a telechat

Summary:
This document describes the method to allow SR to be used for steering packets
with NSH encapsulation between Service Function Forwarders along a given
Service Function Path. The NSH maintains the integrity of the service plane,
the SFC instance context, and any associated metadata.

The draft is very clear and ready for publication.

Major issues: None

Minor issues: None

Nits/editorial comments: None.

Best Regards,
Linda Dunbar


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

Re: [spring] WG adoption call - draft-hu-spring-segment-routing-proxy-forwarding

[Linda Dunbar]

Support WG adoption.

Linda Dunbar


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Thursday, January 13, 2022 5:19 AM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] WG adoption call - 
draft-hu-spring-segment-routing-proxy-forwarding


Dear WG,



This message starts a 2 week WG adoption call, ending 27/01/2022, for 
draft-hu-spring-segment-routing-proxy-forwarding

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hu-spring-segment-routing-proxy-forwarding%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd34d534fd5404e5fca3208d9d6b157ed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637776879466008063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vM3MvCDMe3uEm6cXtLy7NREozhc8WNksBXIFYoU5cXI%3D&reserved=0>



After review of the document please indicate support (or not) for WG adoption 
of the document 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 or review 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 the document.



Thanks!

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

[spring] questions to draft-li-teas-intent-based-routing

[Linda Dunbar]

Robin,

Thank you very much for the nice presentation.

Continue the question I asked during the SPRING Session, is the  "INTENT" in 
your draft meant to identify the characteristics of the flow that the packet 
belongs to? Such as a packet has a "INTENT" value to indicate that it belongs 
to a flow that needs high bandwidth, or another "INTENT" value indicating that 
the packet belongs to a flow that requires low latency?


Who inject the "INTENT" value into the packets? Is it based on some policies? 
If yes, can a node use the same "policies" to steer the packet instead of using 
"INTENT" value?

Thank you very much,

Linda Dunbar

___
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/

[Linda Dunbar]

With multiple vendors having implemented the solution, I strongly support the 
adoption of draft-filsfilscheng-spring-srv6-srh-compression.

Linda Dunbar

From: spring  On Behalf Of Keyur Patel
Sent: Monday, October 11, 2021 12:48 AM
To: Zafar Ali (zali) ; James Guichard 
; SPRING WG 
Cc: spring-cha...@ietf.org; Zafar Ali (zali) 
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG and the WG Chairs,

Network programming model (RFC8986) defines multiple flavors for End, End.X, 
and End.T SIDs. CSID draft builds on it with next and replace flavors for these 
SIDs, optimized for 16 bit and 32 bit SID sizes, respectively. This is just 
like PSP, USP and USD flavors defined in RFC8986 to cover different deployment 
scenarios.

We at Arrcus have implemented CSID solution and also have participated in 
multivendor interop for the solution.

I strongly support the adoption.

Best Regards,
Keyur


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Zafar Ali (zali)" 
mailto:zali=40cisco@dmarc.ietf.org>>
Date: Monday, October 4, 2021 at 8:50 AM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>
Cc: "Zafar Ali (zali)" mailto:z...@cisco.com>>, 
"spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" 
mailto:spring-cha...@ietf.org>>
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG and the chairs,

I strongly support the adoption call

About the matter in the email, the WG has defined a single data plane solution, 
i.e., SRv6 (RFC8402, RFC8754, and RFC8986).
SRv6 as per the inherent nature of the network programming model (RFC8996) 
already defines multiple standardized behaviors.
Clearly, CSID is a single solution based on the SRv6 data plane.

Thanks

Regards ... Zafar


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of James Guichard 
mailto:james.n.guich...@futurewei.com>>
Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG mailto:spring@ietf.org>>
Cc: "spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" 
mailto:spring-cha...@ietf.org>>
Subject: [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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8de269e773ca4459499408d98c7ab2cf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637695280917116632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0GGK8CBENHCpOS2TdHfbxp9ph9k8R9dXMDmJTQWyBUI%3D&reserved=0>
 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8de269e773ca4459499408d98c7ab2cf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637695280917116632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0GGK8CBENHCpOS2TdHfbxp9ph9k8R9dXMDmJTQWyBUI%3D&reserved=0>
 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

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

[Linda Dunbar]

I support adoption.

Linda Dunbar

On Sep 10, 2021, at 12:16 PM, Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
 wrote:

Bruno,

When a WG adopts a design team draft, I assume that the draft becomes subject 
to the following guidelines from RFC7221:

“Once a working group adopts a draft, the document is owned by the working 
group and can be changed however the working group decides, within the bounds 
of IETF process and the working group charter.  Absent explicit agreement, 
adopting a document does not automatically mean that the working group has 
agreed to all of its content.  So a working group (or its charter) might 
explicitly dictate the basis for retaining, removing, or modifying some or  
 all of a draft's content, technical details, or the like. However, in the 
absence of such constraints, it is worth having the adoption process include a 
sub-process of gathering working group concerns about the existing draft and 
flagging them explicitly.”

Do I have that right?

If so, I support adoption of this draft.

Ron



Juniper Business Use Only
From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Tuesday, September 7, 2021 9:13 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] WG Adoption call - 
draft-srcompdt-spring-compression-requirement - 
draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-srcompdt-spring-compression-requirement__%3B!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhUozCY2f%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66b09dd4dfa94d6d0a4f08d974912e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637668989200100131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=e1R7UkjDjwFqoO6Jm7MmQM8ccyaOZX6HnbC1XZTqqAY%3D&reserved=0>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-srcompdt-spring-compression-analysis__%3B!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhc0iIRXo%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66b09dd4dfa94d6d0a4f08d974912e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637668989200100131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hmouQaBZVRbbGj3v1XcK9I6IyGfyftfeHmnNdcUBfPQ%3D&reserved=0>


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 an

Re: [spring] WG Adoption Call for https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

[Linda Dunbar]

Yes, support.

Best regards,
Linda Dunbar

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Monday, June 7, 2021 8:34 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt

Dear WG:

The IPPM WG has adopted 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-srpm-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ippm-stamp-srpm-00&data=04%7C01%7Cldunbar%40futurewei.com%7Cfb3c6d1737a648418bcf08d92a289209%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637587176059822365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q%2B2MGnALPDsEAVrsKLWYBAMtJEHvjZTQ5lCorGJ977E%3D&reserved=0>
 as a WG document. In a previous communication (December 16th 2020), the SPRING 
chairs decided not to adopt 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-gandhi-spring-stamp-srpm-06.txt&data=04%7C01%7Cldunbar%40futurewei.com%7Cfb3c6d1737a648418bcf08d92a289209%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637587176059827333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aGRG8ObRAQxBsAKNGnBL6TPr5AKj2eDFFM5ivbFkKqI%3D&reserved=0>
 into the WG until its companion document was accepted by the IPPM WG. This has 
now happened and therefore we feel it is now time to revisit the WG adoption of 
the SPRING document.

Due to the lapse of several months since the initial WG adoption call, the 
chairs would like to start another 2-week WG adoption call for 
https://www.ietf.org/archive/id/draft-gandhi-spring-stamp-srpm-06.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-gandhi-spring-stamp-srpm-06.txt&data=04%7C01%7Cldunbar%40futurewei.com%7Cfb3c6d1737a648418bcf08d92a289209%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637587176059827333%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aGRG8ObRAQxBsAKNGnBL6TPr5AKj2eDFFM5ivbFkKqI%3D&reserved=0>,
 ending June 21st 2021.

After review of the SPRING document please indicate support (or not) for WG 
adoption to the mailing list. Please also provide comments/reasons for that 
support (or lack thereof) as silence will not be considered as consent.

Thanks!

Jim, Joel & Bruno



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

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

[Linda Dunbar]

 I have finished reading the draft-ietf-spring-segment-routing-policy-09. I 
think the draft is written very clear.

I support the WGLC.



Best Regards,

Linda Dunbar



On Thursday, April 15, 2021, 9:57:11 PM GMT+3, James Guichard 
mailto:james.n.guich...@futurewei.com>> wrote:





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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-segment-routing-policy%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cacf87bb5c7a8401115a908d90bf6509d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637553974852253455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uhM%2B2U1fjrq3tkhxYGzPWCLJEjoD7LKPYQyUfMeQx1k%3D&reserved=0>







___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cacf87bb5c7a8401115a908d90bf6509d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637553974852263449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1H2JGzCyoP9%2BJpSAYjpi6dLLygwsNzmwXFq4glEq9MY%3D&reserved=0>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] some questions about draft-li-spring-tunnel-segment-02

[Linda Dunbar]

Zhenbin, cheng, and Nan,

One more question:
For the Use Case described by 3.1, what is the difference between Tunnel 
Binding SID and the regular Binding SID?  The regular Binding SID can replace 
the SID Z with the actual {E, F, G, H}.
What additional features does the Tunnel Binding SID provide that the original 
Binding SID doesn't?

Thank you
Linda Dunbar

From: Linda Dunbar
Sent: Wednesday, April 21, 2021 10:54 PM
To: draft-li-spring-tunnel-segm...@ietf.org; spring@ietf.org
Subject: some questions about draft-li-spring-tunnel-segment-02

Zhenbin, Cheng, and Nan,

Section 3.2 of the draft-li-spring-tunnel-segment-02 discusses the SR traffic 
traversing non-SR domains.
Do you require a Tunnel Segment that connects 2 (or more) SR islands to be 
preestablished? Can the Tunnel segment be IPsec Tunnel? So that two separate SR 
islands can be connected by the third party network (e.g.,  Internet)?

Are the two SR islands under the same administrative control? i.e., Are the SID 
used by SR Island-1 recognized by nodes within the SR Island-2 ?


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

[spring] some questions about draft-li-spring-tunnel-segment-02

[Linda Dunbar]

Zhenbin, Cheng, and Nan,

Section 3.2 of the draft-li-spring-tunnel-segment-02 discusses the SR traffic 
traversing non-SR domains.
Do you require a Tunnel Segment that connects 2 (or more) SR islands to be 
preestablished? Can the Tunnel segment be IPsec Tunnel? So that two separate SR 
islands can be connected by the third party network (e.g.,  Internet)?

Are the two SR islands under the same administrative control? i.e., Are the SID 
used by SR Island-1 recognized by nodes within the SR Island-2 ?


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

Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

[Linda Dunbar]

I have read the draft. I think it is very useful to have a solution that 
integrates the Network Server Header and the Segment routing.

I support the publication.

Linda Dunbar


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Wednesday, February 10, 2021 2:31 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: draft-ietf-spring-nsh...@ietf.org<mailto:draft-ietf-spring-nsh...@ietf.org>
Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear WG,

This message starts a 2 weeks WG last call for draft-ietf-spring-nsh-sr [1].

After review of the document please indicate whether you believe this document 
should be progressed to the IESG.

In addition to yes/no, please consider providing a technical review of this 
document; in particular if you care for this document.
Indeed, since WG adoption, this document had benefited from little reviews from 
the WG, so we need more review from the SPRING WG.

If you are aware of an implementation of this document, please report the 
implementation either on the list or to the chairs so that the shepherd can 
report implementations in the writeup.

Note that I'll forward that call to the SFC WG.

Thanks!

[1] 
https://tools.ietf.org/html/draft-ietf-spring-nsh-sr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-nsh-sr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C810b29e52e2d4d6c694008d8e21439c5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637507923815289125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FDX50G52uv%2BON5wiuxGYy5n4DSIvYY5CLomkngoMylU%3D&reserved=0>

--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] When we have multiple proposals addressing the same problem [Re: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn]

[Linda Dunbar]

Greg,

Thank you very much for listing all those drafts related to Network Slicing.

But some of the drafts are only describing virtual partitioning of physical 
networks and methods to guarantee their end to end quality. Those virtual 
partitioning of one physical networks using tags (MPLS, VLAN, RT, etc.)  have 
been deployed for decades.

Is there any draft identifying the gaps between virtual partitioning of 
physical network and end to end Network Slicing?  In 3GPP, a Network Slice 
includes the capabilities to manage, control and orchestrate the subset of 
network resources independently from other Network Slices.

Linda Dunbar

From: spring  On Behalf Of Greg Mirsky
Sent: Wednesday, February 3, 2021 4:02 PM
To: Adrian Farrel 
Cc: James Guichard ; spring ; 
spring-cha...@ietf.org
Subject: [spring] When we have multiple proposals addressing the same problem 
[Re: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn]

Dear All,
I've edited the subject though left the original line in place to indicate the 
relationship between threads of discussion.
Several comments already have referenced *bestbar* drafts that, in my 
understanding of them, propose a different solution to the problem addressed in 
draft-dong-spring-sr-for-enhanced-vpn. The situation when more than a single 
technical solution being offered is not unusual, probably that is what one can 
expect at IETF. And I think that "let's ensure that this is solid technical 
work while allowing the market to decide whether it is better than others" is 
very reasonable and removes non-technical considerations from a WG AP (or LC). 
If we use that paradigm, other solutions, for example, *bestbar* drafts, would 
be considered for adoption and, if adopted, progress on the Standards track. If 
that is what the WG decides to do, standardize sound technical solutions, no 
matter how many, then, by all means, I support it. What I feel uneasy about is 
if adopting one proposal would create a situation preventing standardization of 
other solutions. The WG faced a similar problem just recently and a design team 
has been formed with a clear task and deliverables. Perhaps another design team 
can be formed to work to analyze the problem and proposed solutions? I've 
attempted to capture what seems to be relevant to the problem:

  *   related to the data plane

https://tools.ietf.org/html/draft-ali-spring-network-slicing-building-blocks-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ali-spring-network-slicing-building-blocks-03&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284047643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=51SeXlrqKkEPcZlZ%2B1crrkbbd2zmgPmY2ZUlV%2B7tL94%3D&reserved=0>

https://tools.ietf.org/html/draft-peng-teas-network-slicing-04<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-peng-teas-network-slicing-04&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284047643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Ehe%2B2jm5%2BId2FHzDmsuV6uB%2BCjjSBrY9vq2EHD6Lwhs%3D&reserved=0>

https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bestbar-teas-ns-packet-01&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284057627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=C2NNOnyu5%2BB9RhZCGdNRcl34KSjPJhhBGtxXLn2%2BNwo%3D&reserved=0>

https://tools.ietf.org/html/draft-bestbar-spring-scalable-ns-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bestbar-spring-scalable-ns-00&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284057627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=vgrBT6GHXtqQmmCuzlpxiMG%2BP5lHoVbsKfeC671ZMJ8%3D&reserved=0>

https://tools.ietf.org/html/draft-decraene-mpls-slid-encoded-entropy-label-id-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-decraene-mpls-slid-encoded-entropy-label-id-00&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284067622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=bou6PkNKBYw2vpWL1Novlh%2B4Ohfa1lbR

[spring] Comments to draft-ali-spring-network-slicing-building-blocks-03

[Linda Dunbar]

Zafar, el al,

draft-ali-spring-network-slicing-building-blocks-03 has a very comprehensive 
description of various components of SR and how they can be put together.

However, I find the draft hasn't touched upon addressing the fundamental 
features of Network Slicing.
Maybe the term "network slice" means very different things to different people.

In 3GPP, a Network Slice includes the capabilities to manage, control and 
orchestrate the subset of network resources independently from other Network 
Slices.

The draft has a very good description on how SR achieves the On-demand policy, 
automatic steering and loop prevention. But the draft doesn't have any 
description on how subscribers can view and manage their dedicated network 
resources, or even what kind of network resources are visible/controllable by 
subscribers, which are the key components of Network Slicing. For example, can 
SR allows a subscriber to specify their traffic not to be shared on link/nodes 
with others?

Best regards,
Linda Dunbar
___
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

[Linda Dunbar]

Dear WG,

I support the WG adoption of the draft.
It is true that the enhanced-vpn mechanism requires additional processing.
For some special environment, such as the 5G  Edge Computing servers within  N6 
network, some operators may be willing to add the additional processing (in the 
confined network) to achieve the desired QoS for the premium services.
In addition, with zero rating (or zero rating +) applications increase, the 
future may call for  more premium VPN+ services.

Linda Dunbar


From: spring  On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 5:47 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] 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 10th 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

Re: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment

[Linda Dunbar]

Support the WG Adoption.

Linda Dunbar

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Wednesday, November 4, 2020 1:39 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for draft-li-spring-srv6-path-segment

Dear WG:

This message starts a 3 week WG adoption call for 
https://tools.ietf.org/html/draft-li-spring-srv6-path-segment-07<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-spring-srv6-path-segment-07&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4b5426e87714405de4d908d88201f13c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637402292162021371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w54F5kk4ulQC5%2FEM6QMYkleSWhlDMVgYZP4g8eP96RE%3D&reserved=0>,
 ending November 24th 2020. Please note that this document has several changes 
from v-06 that were requested by the SPRING chairs. For this reason, the chairs 
have extended the adoption call for an additional week to allow the WG enough 
time to review these changes before deciding on WG adoption.

After review of the document please indicate support (or not) for WG adoption 
to the mailing list. Please also provide comments/reasons for that support (or 
lack thereof) as silence will not be considered as consent.

Thanks!

Jim, Bruno & Joel





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

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

[Linda Dunbar]

Support,

Linda Dunbar

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Thursday, October 22, 2020 8:52 PM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: ippm-cha...@ietf.org<mailto:ippm-cha...@ietf.org>; 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: [spring] WG Adoption Call for 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Dear WG:

This message starts a 3 week WG adoption call for 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gandhi-spring-stamp-srpm-03&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C290b83cf837740a31e3e08d87ae4aaf9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637394469836493913%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2BjqqrHmcxsSqlFXQFJfZ3WDT3LnL4Uc%2BL1cq4BN9AgI%3D&reserved=0>,
 ending November 12th 2020. Please note that this document has several changes 
from v-02 that were requested by the SPRING and IPPM chairs. For this reason, 
the chairs have extended the adoption call for an additional week to allow the 
WG enough time to review these changes before deciding on WG adoption.

Some background:

Several review comments were received previously for document 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gandhi-spring-stamp-srpm-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C290b83cf837740a31e3e08d87ae4aaf9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637394469836503871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=J%2FKQQ6OROX0Y8bG48yx6RyJQ4xeacP%2F17q%2FtVNBbSCM%3D&reserved=0>.
 The SPRING and IPPM chairs considered those comments, and upon review of this 
version of the document, determined the following:


  *   The SPRING document should describe only the procedures relevant to 
SPRING with pointers to non-SPRING document/s that define any extensions. 
Several extensions including Control Code Field Extension for STAMP Messages, 
Loss Measurement Query Message Extensions, Loss Measurement Response Message 
Extensions, Node Address TLV Extensions, and Return Path TLV Extensions were 
included in 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gandhi-spring-stamp-srpm-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C290b83cf837740a31e3e08d87ae4aaf9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637394469836503871%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=J%2FKQQ6OROX0Y8bG48yx6RyJQ4xeacP%2F17q%2FtVNBbSCM%3D&reserved=0>
 and should be removed from the SPRING document.
  *   The STAMP extensions included in 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gandhi-spring-stamp-srpm-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C290b83cf837740a31e3e08d87ae4aaf9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637394469836513827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3mnV0jbLMe5i2D%2B3v2gocr%2BhCCsc9e8PHmFQDdNXuzM%3D&reserved=0>
 should be described in a new document published in the IPPM WG.

These conclusions were discussed with the authors of 
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gandhi-spring-stamp-srpm-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C290b83cf837740a31e3e08d87ae4aaf9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637394469836513827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=3mnV0jbLMe5i2D%2B3v2gocr%2BhCCsc9e8PHmFQDdNXuzM%3D&reserved=0>
 the result of which is the publication of the following two documents:


  *   
https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gandhi-spring-stamp-srpm-03&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C290b83cf837740a31e3e08d87ae4aaf9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637394469836523784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=fMahqEAbjUw3dYas4JDyURI1qaI6WKwLPoGdJ%2BZYdRw%3D&reserved=0>.
 The subject of this WG adoption call.
  *   
https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-gandhi-ippm-st

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

[Linda Dunbar]

I support the WG adoption of this draft.

I think it is a really good idea for each Virtual Network to have its own SIDs.
A couple questions to the authors:

Page 9: Figure 1: The Red network has same SID on A & B for the path between 
them. But between B & E there are different SIDs. Is it intended?
What scenario requires same SID on both nodes?

Page 10: Section 4.3: the paragraph states that each node should advertise the 
identifiers of the Virtual networks it participates in: 1) does each Virtual 
Network has its own advertisement?  i.e. if a node supports 5 Virtual Networks, 
the node sends out 5 independent advertisements?  2) The network controller 
configures the SIDs for each node. Why not let the network controller manage 
the advertisement?

Cheers,
Linda

From: spring  On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 6:17 AM
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

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 29th 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

Re: [spring] WG Adoption Call for draft-raza-spring-srv6-yang

[Linda Dunbar]

I support the adoption.



Linda Dunbar




发件人: spring [spring-boun...@ietf.org] 代表 James Guichard 
[james.n.guich...@futurewei.com]
发送时间: 2020年7月14日 5:52
收件人: spring@ietf.org<mailto:spring@ietf.org>
抄送: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
主题: [spring] WG Adoption Call for draft-raza-spring-srv6-yang
Dear WG:

This email begins a 2 week WG adoption call for 
https://datatracker.ietf.org/doc/draft-raza-spring-srv6-yang/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-raza-spring-srv6-yang%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C606c2ad2a1a1434f020a08d828c2aaa7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637304163851692570&sdata=y4z9LYWiFK2IvimuuPfMruCbj1bc8ieMAqNJamehnAo%3D&reserved=0>
 ending Monday 27th 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

Re: [spring] 答复: WG LC https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/

[Linda Dunbar]

Support,



Linda Dunbar





 --









Dear SPRING WG:

This email starts a two week WG LC for 
https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-yang%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7dcc1881197c462b6d9f08d817d9938a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637285570558970388&sdata=3ea4CXetcwbZqg8pDS6mvqmrJEeYfmelPk95m3JI1RU%3D&reserved=0>.

Substantive comments should be directed to the mailing list no later than July 
7th. Editorial suggestions can be sent to the authors.

Thanks!

Jim, Joel & Bruno

___
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] WG adoption call for draft-voyer-spring-sr-replication-segment

[Linda Dunbar]

Support. 
Linda Dunbar


-Original Message-
From: spring  On Behalf Of bruno.decra...@orange.com
Sent: Monday, June 22, 2020 7:46 AM
To: spring@ietf.org
Subject: [spring] WG adoption call for draft-voyer-spring-sr-replication-segment

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-voyer-spring-sr-replication-segment&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C5a5f27c5b15f4610866008d817e61e10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637285624435515763&sdata=7aLMsRsOZRlkHGMiFlxaN%2BtKemetGaFeZmM87HjGrYs%3D&reserved=0
[2] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FtW-HHK7QzCw3ZBbFD0Dl7Eszd3k%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C5a5f27c5b15f4610866008d817e61e10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637285624435525755&sdata=QVLNT2s%2Bu2kBNBelLdiG7bzjlBAodS4XaOFiBGTK%2FYw%3D&reserved=0


_

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C5a5f27c5b15f4610866008d817e61e10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637285624435525755&sdata=jd5wUknMp1LNFiBfTeisu1oAJyYQAPRTkAzVeL%2B%2F5uI%3D&reserved=0

___
spring mailing list
spring@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C5a5f27c5b15f4610866008d817e61e10%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637285624435525755&sdata=jd5wUknMp1LNFiBfTeisu1oAJyYQAPRTkAzVeL%2B%2F5uI%3D&reserved=0

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

[spring] Questions about draft-camarilloelmalky-springdmm-srv6-mob-usecases-02

[Linda Dunbar]

Pablo, et al,

Your draft assumes that UE to gNB is with the SRv6 instead of 3GPP's GTP? If 
you can't convince 3GPP to replace their GTP, what kind of scenarios will 
deploy SRv6 from UE -gNB-UPF?

In Section 3.1.3, you stated that SRv6 offers Load balancing among VNFs, does 
it require the head node to be aware of all the instances to make it possible? 
If the Mobile operators manage their VNFs transparent of the UE, can SRv6 still 
offer load balancing among VNFs? If Yes, How?

In Section 3.2.1.1.  You stated the value of SRv6 can automatically connects a 
user to its home wireless network when the user enters the house. Does it 
require UE be the SRv6 head node?
Most likely the home access network provider is different from the user's 
mobile network provider, then this automatically switch over won't happen, 
correct?


Thank you
Linda Dunbar

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

[spring] Can features described by draft-ietf-spring-sr-service-programming-01 be supported by draft-ietf-spring-srv6-network-programming-08?

[Linda Dunbar]

Authors of draft-ietf-spring-sr-service-programming-01:

"draft-ietf-spring-sr-service-programming" specifies Service SIDs to be 
embedded into the SID list. Does it make the SID list even longer? For example, 
 if a packet needs to be steered through the network by 3 SIDs (S1, S2, S3), 
Service SIDs will be the additional SIDs to be added to the packet header?

It seems straight forward for draft-ietf-spring-srv6-network-programming to add 
an instruction to forward the packet to a specific service Function.  Why not 
using draft-ietf-spring-srv6-network-programming to steer packets to specific 
service functions?
What features specified by draft-ietf-spring-sr-service-programming that can't 
be achieved by draft-ietf-spring-srv6-network-programming?

Some minor questions:  What is the ENH in Section 6.1.2? You have ENH = 59, ENH 
= 4,  Are  you talking the Ethernet frames being encapsulated by SRH header?
The inner payload are IP frames, aren't they?

Thank you very much,

Linda Dunbar



___
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

[Linda Dunbar]

Support.

Linda Dunbar


From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Thursday, December 19, 2019 11:54 AM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-07%23section-9.1&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2b3d4216c5634c6cc22b08d7903bfeb7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637136459687653789&sdata=monj6Xgn6J%2FWj%2BxIuahXGt3%2F98y5Dyt11c9LTM3Hr%2Fg%3D&reserved=0>

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-5.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-srv6-network-programming-07%23section-5.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2b3d4216c5634c6cc22b08d7903bfeb7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637136459687653789&sdata=64qEwJbzBLCKLZn7KcORV6j1uQiCZ1f8V408Jm75R8U%3D&reserved=0>

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fprotocol-numbers%2Fprotocol-numbers.xhtml&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2b3d4216c5634c6cc22b08d7903bfeb7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637136459687663738&sdata=R%2F%2BzBDtuswQYvSJtqYQNcyAcNczKAbJguhAzL8n3Kyk%3D&reserved=0>



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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7120%23section-2&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2b3d4216c5634c6cc22b08d7903bfeb7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637136459687663738&sdata=27xnPjT4r8fa5Cu%2FyJ%2BFx%2FK%2F2Id6imhUj0pntQNo16k%3D&reserved=0>



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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fproceedings%23intarea&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2b3d4216c5634c6cc22b08d7903bfeb7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637136459687673697&sdata=sbRmvnHcBs34Yxdkmyxo61r4f0spJzgbCysWHn9OSMM%3D&reserved=0>



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 privilegie

Re: [spring] IETF 106 SPRING WG Agenda uploaded

[Linda Dunbar]

Bruno, and Peng ShuPing,

I requested a presentation slot on Oct 29 (see the attached email), is it 
neglect or intentional of not having it on the SPRING agenda?

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/
Speaker: Linda Dunbar


Possible to add it to Thursday afternoon session?

Thank you.

Linda

From: spring  On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, November 13, 2019 8:21 PM
To: spring@ietf.org
Cc: Pengshuping (Peng Shuping) ; spring-cha...@ietf..org
Subject: Re: [spring] IETF 106 SPRING WG Agenda uploaded

Hi all,


  *   For the presenters in the Monday morning session, it would be good if you 
could upload your slides no later than Sunday 2PM (Singapore time).

Please privilege the pdf file format over ppt. The experience prove that this 
is better for everyone, both for presenting during the meeting and for archive.

Thank you.
--Bruno

From: Pengshuping (Peng Shuping) [mailto:pengshup...@huawei.com]
Sent: Wednesday, November 13, 2019 12:26 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
Subject: IETF 106 SPRING WG Agenda uploaded

Hi all,

The SPRING WG agenda is now available and can be found at:
https://datatracker.ietf.org/meeting/106/materials/agenda-106-spring-11<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fagenda-106-spring-11&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C47f4500c3c9b479fbc1a08d76833ff71%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637092444861193042&sdata=zZRUI%2BCuJuFLO%2FG5ZI5v9NfMEQOy3DBD7ygCLe4nliQ%3D&reserved=0>

Any comments on the current agenda please inform the Chairs.

Please note that we have got two sessions this time.
To the presenters, please upload your slides to the corresponding session at:
https://datatracker.ietf.org/meeting/106/session/spring<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fsession%2Fspring&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C47f4500c3c9b479fbc1a08d76833ff71%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637092444861193042&sdata=6Lp2QJJ8IImRrPCeRcLlt2xGGWYixw58kCYG61k7HKo%3D&reserved=0>

For the presenters in the Monday morning session, it would be good if you could 
upload your slides no later than Sunday 2PM (Singapore time). Thank you!

Looking forwards to meeting you all in Singapore. :)

Best Regards,
Shuping

_



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.
--- Begin Message ---
SPRING chairs,

Can we get 10 minutes slot for briefing the following draft?
https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/
Speaker: Linda Dunbar

We will submit the updated draft before the cutoff date and start the 
discussion on the mailing list too.

Linda

From: spring  On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, October 23, 2019 7:28 AM
To: SPRING WG List 
Cc: spring-cha...@ietf.org
Subject: [spring] IETF 106 - SPRING agenda


Hi SPRING,



The preliminary IETF meeting agenda is at 
https://datatracker.ietf.org/meeting/106/agenda.html<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fagenda.html&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ca64250d1e1f54ff492c008d757b4832b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637074305149047822&sdata=iSs5Zmt0DN3plM0sFvlBKDN6Iw4RI9dnPC1EIcN4PG8%3D&reserved=0>
 .



For IETF 106, we're scheduled to meet twice:

13:30-15:30Monday Afternoon session I

15:50-17:20Thursday Afternoon session II





Rob and I would like to ask folks to send requests for presentation slots

in the SPRING meeting. Please indicate:



   - the name of the draft you'd like to present,

   - the speaker's name,

   - the amount of time you would like to be allotted - this should cover

   *both* your presentation and discussion.



If you're planning to present a n

Re: [spring] IETF 106 - SPRING agenda

[Linda Dunbar]

SPRING chairs,

Can we get 10 minutes slot for briefing the following draft?
https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/
Speaker: Linda Dunbar

We will submit the updated draft before the cutoff date and start the 
discussion on the mailing list too.

Linda

From: spring  On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, October 23, 2019 7:28 AM
To: SPRING WG List 
Cc: spring-cha...@ietf.org
Subject: [spring] IETF 106 - SPRING agenda


Hi SPRING,



The preliminary IETF meeting agenda is at 
https://datatracker.ietf.org/meeting/106/agenda.html<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fagenda.html&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ca64250d1e1f54ff492c008d757b4832b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637074305149047822&sdata=iSs5Zmt0DN3plM0sFvlBKDN6Iw4RI9dnPC1EIcN4PG8%3D&reserved=0>
 .



For IETF 106, we're scheduled to meet twice:

13:30-15:30Monday Afternoon session I

15:50-17:20Thursday Afternoon session II





Rob and I would like to ask folks to send requests for presentation slots

in the SPRING meeting. Please indicate:



   - the name of the draft you'd like to present,

   - the speaker's name,

   - the amount of time you would like to be allotted - this should cover

   *both* your presentation and discussion.



If you're planning to present a new non-working group draft, please first

post it to the list. If you're presenting an update to an existing draft,

please send an update mail to the list highlighting the

changes that you've made.



There's a handy check-list for presenting at a SPRING meeting on the wiki

https://trac.ietf.org/trac/spring/wiki/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fspring%2Fwiki%2FChecklist%2520for%2520presenting%2520at%2520a%2520SPRING%2520meeting&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ca64250d1e1f54ff492c008d757b4832b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637074305149057813&sdata=iHYVRxNPUCpDjBwQCbhwxd68L7VP6ggyhk9j%2FzRKaEA%3D&reserved=0>
 .



We tend to be oversubscribed on meeting agenda slots -- please consider

carefully whether there are items in your update that really benefit from

face-to-face discussion. If the draft has simply been refreshed since last

time it was presented, with no material changes, please consider not

requesting a slot to make our lives easier!



Please have your requests to us by Friday 2019-11-01. We'd like your

slides *Sunday* November 17th at 10:00 local time at the very latest to give us 
time

to be able to put together the materials for remote participants.



Thanks,

Rob & 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] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

[Linda Dunbar]

Jeff,

There are several scenarios (which have been documented in the draft):
One scenario has SDWAN edge node not directly attached to SR edge. The draft is 
suggesting VxLAN or GRE to connect the SDWAN edge and the SR edge.

Linda

From: Jeff Tantsura 
Sent: Thursday, July 18, 2019 2:25 PM
To: spring ; SPRING WG ; 徐小虎(义先) 
; Linda Dunbar 
Subject: RE: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Linda,

In context of draft-ietf-mpls-sr-over-ip it would be IP->SRinUDP->SR-native-> 
SRinUDP->IP

Cheers,
Jeff
On Jul 18, 2019, 9:16 AM -0700, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>, wrote:

Jeff,

For SDWAN case, the Source node and Destination nodes (a.k.a. SDWAN edge nodes) 
are IP based.

So it should be reversed, IP segments -> SR segments which include both SRv6 & 
MPLS-SR -> IP segments

Linda

From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Monday, July 15, 2019 5:48 PM
To: spring mailto:spring-boun...@ietf.org>>; SPRING WG 
mailto:spring@ietf.org>>; 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: RE: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Linda,

What you want is to use native MPLS when available and encapsulate MPLS packets 
in IP/UDP when you need to travers IP, you destination in the imposed IP header 
would be that of the next SR capable device as described in 
draft-ietf-mpls-sr-over-ip.

Cheers,
Jeff
On Jul 15, 2019, 3:24 PM -0700, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>, wrote:

Jeff,

The draft-ietf-mpls-sr-over-ip only has MPLS packets being tunneled by IP, but 
not reversed (IP packets tunneled over MPLS).

Do you think it worthwhile to add some similar sections (of course with 
different content), such as Forwarding entry Construction, forwarding 
procedures as in draft-ietf-mpls-sr-over-ip?

Linda

From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Tuesday, July 09, 2019 4:03 PM
To: spring mailto:spring-boun...@ietf.org>>; Linda 
Dunbar mailto:linda.dun...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>; 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>
Subject: Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

+1

take a look at draft-ietf-mpls-sr-over-ip

Cheers,
Jeff
On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>, wrote:
Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as 
to indicate the preferred path? For more details, please read 
https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C35aa8f8c9b52469f571d08d70bb5b13f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636990747306731132&sdata=UtxB8Z%2B02FON9fBh%2BmVuqo5P3xGCHUb0Bf%2BfSKFFr2M%3D&reserved=0>

Best regards,
Xiaohu

--
From:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; SPRING WG 
mailto:spring@ietf.org>>
Subject:Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Sorry, I meant to ask:

When the SDWAN edge nodes are NOT directly connected to the PEs of SR domain, 
is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate 
the desired SR Path?

Linda

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN 
bandwidth from multiple service providers to get better WAN bandwidth 
management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or 
its network service provider may not have the direct links to the Cloud DCs 
that are optimal for hosting the enterprise’s specific workloads/Apps. Under 
those circumstances, SD-WAN is a very flexible

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

[Linda Dunbar]

Jeff,

For SDWAN case, the Source node and Destination nodes (a.k.a. SDWAN edge nodes) 
are IP based.

So it should be reversed, IP segments -> SR segments which include both SRv6 & 
MPLS-SR -> IP segments

Linda

From: Jeff Tantsura 
Sent: Monday, July 15, 2019 5:48 PM
To: spring ; SPRING WG ; 徐小虎(义先) 
; Linda Dunbar 
Subject: RE: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Linda,

What you want is to use native MPLS when available and encapsulate MPLS packets 
in IP/UDP when you need to travers IP, you destination in the imposed IP header 
would be that of the next SR capable device as described in 
draft-ietf-mpls-sr-over-ip.

Cheers,
Jeff
On Jul 15, 2019, 3:24 PM -0700, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>, wrote:


Jeff,

The draft-ietf-mpls-sr-over-ip only has MPLS packets being tunneled by IP, but 
not reversed (IP packets tunneled over MPLS).

Do you think it worthwhile to add some similar sections (of course with 
different content), such as Forwarding entry Construction, forwarding 
procedures as in draft-ietf-mpls-sr-over-ip?

Linda

From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Sent: Tuesday, July 09, 2019 4:03 PM
To: spring mailto:spring-boun...@ietf.org>>; Linda 
Dunbar mailto:linda.dun...@futurewei.com>>; SPRING 
WG mailto:spring@ietf.org>>; 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>
Subject: Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

+1

take a look at draft-ietf-mpls-sr-over-ip

Cheers,
Jeff
On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>, wrote:
Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as 
to indicate the preferred path? For more details, please read 
https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce2ef92e9de2143db0be208d709768846%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636988277015484955&sdata=hasaujqJuyv%2FvF2rnj8Gv%2FM%2BUVAUN5q2A6djQQBvl5g%3D&reserved=0>

Best regards,
Xiaohu

--
From:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; SPRING WG 
mailto:spring@ietf.org>>
Subject:Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Sorry, I meant to ask:

When the SDWAN edge nodes are NOT directly connected to the PEs of SR domain, 
is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate 
the desired SR Path?

Linda

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN 
bandwidth from multiple service providers to get better WAN bandwidth 
management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or 
its network service provider may not have the direct links to the Cloud DCs 
that are optimal for hosting the enterprise’s specific workloads/Apps. Under 
those circumstances, SD-WAN is a very flexible choice to interconnect the 
enterprise on-premises data centers & branch offices to its desired Cloud DCs...
However, SD-WAN paths over public internet can have unpredictable performance, 
especially over long distances and cross state/country boundaries. Therefore, 
it is highly desirable to place as much as possible the portion of SD-WAN paths 
over service provider VPN (e.g. enterprise’s existing VPN) that have guaranteed 
SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce2ef92e9de2143db0be208d709768846%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636988277015484955&sdata=oPw5CZJK%2BtRB68%2FbGa9m%2BIhS8WgweEIb1Ne2yIRGnkY%3D&reserved=0>
 describe

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

[Linda Dunbar]

Jeff,

The draft-ietf-mpls-sr-over-ip only has MPLS packets being tunneled by IP, but 
not reversed (IP packets tunneled over MPLS).

Do you think it worthwhile to add some similar sections (of course with 
different content), such as Forwarding entry Construction, forwarding 
procedures as in draft-ietf-mpls-sr-over-ip?

Linda

From: Jeff Tantsura 
Sent: Tuesday, July 09, 2019 4:03 PM
To: spring ; Linda Dunbar 
; SPRING WG ; 徐小虎(义先) 

Subject: Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

+1

take a look at draft-ietf-mpls-sr-over-ip

Cheers,
Jeff
On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) 
mailto:xiaohu@alibaba-inc.com>>, wrote:

Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as 
to indicate the preferred path? For more details, please read 
https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf52fb4f3cd9849504fca08d704b0d42f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636983029839380080&sdata=rORtMbo%2FgwAi1PypRoiiRcKkw%2ByLqhvgLKKqnetp5jA%3D&reserved=0>

Best regards,
Xiaohu

--
From:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; SPRING WG 
mailto:spring@ietf.org>>
Subject:Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Sorry, I meant to ask:

When the SDWAN edge nodes are NOT directly connected to the PEs of SR domain, 
is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate 
the desired SR Path?

Linda

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN 
bandwidth from multiple service providers to get better WAN bandwidth 
management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or 
its network service provider may not have the direct links to the Cloud DCs 
that are optimal for hosting the enterprise’s specific workloads/Apps. Under 
those circumstances, SD-WAN is a very flexible choice to interconnect the 
enterprise on-premises data centers & branch offices to its desired Cloud DCs...
However, SD-WAN paths over public internet can have unpredictable performance, 
especially over long distances and cross state/country boundaries. Therefore, 
it is highly desirable to place as much as possible the portion of SD-WAN paths 
over service provider VPN (e.g. enterprise’s existing VPN) that have guaranteed 
SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf52fb4f3cd9849504fca08d704b0d42f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636983029839390078&sdata=aiQ6DE4Cq9Y1J%2B%2FsfbHNwlRblnBYB%2BDDaqGXs1CZBIw%3D&reserved=0>
 describes a method to enforce a SD-WAN path’s head-end selected route 
traversing through a list of specific nodes of multiple network segments 
without requiring the nodes in each network segments to have the intelligence 
(or maintaining states) of selecting next hop or next segments.

When a SR domain has multiple PEs with ports facing the external networks (such 
as the public internet or LTE termination), SD-WAN paths can traverse the SR 
domain via different ingress/egress PEs resulting in different E2E performance.

Even with the same ingress/egress, some flows may need different segments 
across the SR Domain. It is not practical, or even possible, for PEs to 
determine which Apps’ flows should egress.
Segment Routing can be used to steer packets (or path) to traverse the explicit 
egress node, or explicit segments through the SR Domain based on the SLA 
requested by the SD-WAN head-end nodes.

When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it 
appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the 
desired SR Path?

We are looking f

Re: [spring] Agenda for IETF 105 Published

[Linda Dunbar]

Bruno,

Why SPRING not request more time for IETF105?
SPRING had more time request than the WG session in IETF104. It happens again 
for IETF105.
Many WGs have multiple sessions, e.g. IDR has 3 sessions in IETF105; RTGwg has 
2 sessions in IETF105, etc.

Linda Dunbar


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Thursday, July 11, 2019 5:38 PM
To: SPRING WG List
Subject: [spring] Agenda for IETF 105 Published

Hi SPRING WG,

Bruno and I have published the agenda for IETF 105 -- please see 
https://datatracker.ietf.org/doc/agenda-105-spring/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fagenda-105-spring%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C6455eb609f084be7e91908d7095d1bfc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636988167826701223&sdata=eHT5FQDQxIngMYuXzrLjXSr0QRvA47Vt86h4szbe9W0%3D&reserved=0>
 for details.

Once again, we were vastly oversubscribed for time in this meeting - with 
almost 5 hours of requests for a 2 hour meeting. Most of these requests are for 
documents that are not discussed on the mailing list, and many of them are for 
new work. This makes the job of making sure that we have productive time 
face-to-face as a working group very difficult for the chairs. This is 
something that Bruno and I are discussing, and will aim to cover during our 
short slot at the beginning of the agenda.

To make sure that our meeting is as productive as possible:
·if you're a WG participant: please read the drafts before the meeting,
·if you're presenting: please avoid giving detailed overviews of the 
content of your document, and focus on outstanding open technical issues, or 
questions that you have for the SPRING working group.
If you have been allocated time, please send your slides by Monday July 22nd, 
at 10:00 EST. Slides that are received after this time may not be included in 
the meeting materials.

If you were not allocated time, please use this as a gentle shove to discuss 
your draft on the mailing list.

We look forward to meeting in Montréal.

Safe travels,
Bruno and 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] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

[Linda Dunbar]

Xiao Hu,

Thank you very much for the suggestion. If the SDWAN edge node supports MPLS, 
MPLSoUDP is definitely a good choice. I will add it to the document.
When an SDWAN edge nodes doesn’t support MPLS,  any other suggestions in 
addition to GRE or VxLAN?

Linda

From: 徐小虎(义先) 
Sent: Tuesday, July 09, 2019 1:45 AM
To: spring ; Linda Dunbar 
; SPRING WG 
Subject: Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as 
to indicate the preferred path? For more details, please read 
https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2d347a69022c4c1b9bbc08d70439049d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636982515250840448&sdata=g%2F1eMkVoC9OtHP71TdtalD0qGJ2L0z6yTg8Wg634CDI%3D&reserved=0>

Best regards,
Xiaohu

--
From:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; SPRING WG 
mailto:spring@ietf.org>>
Subject:Re: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

Sorry, I meant to ask:

When the SDWAN edge nodes are NOT directly connected to the PEs of SR domain, 
is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate 
the desired SR Path?

Linda

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN 
bandwidth from multiple service providers to get better WAN bandwidth 
management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or 
its network service provider may not have the direct links to the Cloud DCs 
that are optimal for hosting the enterprise’s specific workloads/Apps. Under 
those circumstances, SD-WAN is a very flexible choice to interconnect the 
enterprise on-premises data centers & branch offices to its desired Cloud DCs...
However, SD-WAN paths over public internet can have unpredictable performance, 
especially over long distances and cross state/country boundaries. Therefore, 
it is highly desirable to place as much as possible the portion of SD-WAN paths 
over service provider VPN (e.g. enterprise’s existing VPN) that have guaranteed 
SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2d347a69022c4c1b9bbc08d70439049d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636982515250840448&sdata=cPBlLhmj81J9T7d6k1khbnP33gQZwEOPCy0FYwn5U7s%3D&reserved=0>
 describes a method to enforce a SD-WAN path’s head-end selected route 
traversing through a list of specific nodes of multiple network segments 
without requiring the nodes in each network segments to have the intelligence 
(or maintaining states) of selecting next hop or next segments.

When a SR domain has multiple PEs with ports facing the external networks (such 
as the public internet or LTE termination), SD-WAN paths can traverse the SR 
domain via different ingress/egress PEs resulting in different E2E performance.

Even with the same ingress/egress, some flows may need different segments 
across the SR Domain. It is not practical, or even possible, for PEs to 
determine which Apps’ flows should egress.
Segment Routing can be used to steer packets (or path) to traverse the explicit 
egress node, or explicit segments through the SR Domain based on the SLA 
requested by the SD-WAN head-end nodes.

When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it 
appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the 
desired SR Path?

We are looking for feedback, criticisms, or suggestion on the the proposed 
approach.

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

Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

[Linda Dunbar]

Sorry, I meant to ask:

When the SDWAN edge nodes are NOT directly connected to the PEs of SR domain, 
is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate 
the desired SR Path?

Linda

From: spring  On Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG 
Subject: [spring] Seeking comments for 
draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly 
connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR 
path?

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN 
bandwidth from multiple service providers to get better WAN bandwidth 
management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or 
its network service provider may not have the direct links to the Cloud DCs 
that are optimal for hosting the enterprise's specific workloads/Apps. Under 
those circumstances, SD-WAN is a very flexible choice to interconnect the 
enterprise on-premises data centers & branch offices to its desired Cloud DCs..
However, SD-WAN paths over public internet can have unpredictable performance, 
especially over long distances and cross state/country boundaries. Therefore, 
it is highly desirable to place as much as possible the portion of SD-WAN paths 
over service provider VPN (e.g. enterprise's existing VPN) that have guaranteed 
SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1538194078e5452339f108d703f1c90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636982209309189471&sdata=xnGEOr4OENlRDmgfwT4sWiDIHALPOuKFke%2FELyXsmG4%3D&reserved=0>
 describes a method to enforce a SD-WAN path's head-end selected route 
traversing through a list of specific nodes of multiple network segments 
without requiring the nodes in each network segments to have the intelligence 
(or maintaining states) of selecting next hop or next segments.

When a SR domain has multiple PEs with ports facing the external networks (such 
as the public internet or LTE termination), SD-WAN paths can traverse the SR 
domain via different ingress/egress PEs resulting in different E2E performance.

Even with the same ingress/egress, some flows may need different segments 
across the SR Domain. It is not practical, or even possible, for PEs to 
determine which Apps' flows should egress.
Segment Routing can be used to steer packets (or path) to traverse the explicit 
egress node, or explicit segments through the SR Domain based on the SLA 
requested by the SD-WAN head-end nodes.

When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it 
appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the 
desired SR Path?

We are looking for feedback, criticisms, or suggestion on the the proposed 
approach.

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

[spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

[Linda Dunbar]

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN 
bandwidth from multiple service providers to get better WAN bandwidth 
management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or 
its network service provider may not have the direct links to the Cloud DCs 
that are optimal for hosting the enterprise's specific workloads/Apps. Under 
those circumstances, SD-WAN is a very flexible choice to interconnect the 
enterprise on-premises data centers & branch offices to its desired Cloud DCs.
However, SD-WAN paths over public internet can have unpredictable performance, 
especially over long distances and cross state/country boundaries. Therefore, 
it is highly desirable to place as much as possible the portion of SD-WAN paths 
over service provider VPN (e.g. enterprise's existing VPN) that have guaranteed 
SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ 
describes a method to enforce a SD-WAN path's head-end selected route 
traversing through a list of specific nodes of multiple network segments 
without requiring the nodes in each network segments to have the intelligence 
(or maintaining states) of selecting next hop or next segments.

When a SR domain has multiple PEs with ports facing the external networks (such 
as the public internet or LTE termination), SD-WAN paths can traverse the SR 
domain via different ingress/egress PEs resulting in different E2E performance.

Even with the same ingress/egress, some flows may need different segments 
across the SR Domain. It is not practical, or even possible, for PEs to 
determine which Apps' flows should egress.
Segment Routing can be used to steer packets (or path) to traverse the explicit 
egress node, or explicit segments through the SR Domain based on the SLA 
requested by the SD-WAN head-end nodes.

When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it 
appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the 
desired SR Path?

We are looking for feedback, criticisms, or suggestion on the the proposed 
approach.

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

Re: [spring] SPRING at IETF 105 Montréal

[Linda Dunbar]

Rob and Bruno:

Can we request a 10-minute slot for SPRING for SDWAN? We have been working on 
merging the following drafts:
https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/
https://datatracker.ietf.org/doc/draft-dukes-spring-sr-for-sdwan/

Linda
From: spring  On Behalf Of Rob Shakir
Sent: Thursday, June 27, 2019 12:58 AM
To: SPRING WG List 
Cc: spring-cha...@ietf.org
Subject: [spring] SPRING at IETF 105 Montréal

Hi SPRING,

For IETF 105, we're scheduled to meet on Wednesday morning, for a two hour 
meeting slot (10:00-12:00). The prelimary IETF meeting is at 
https://datatracker.ietf.org/meeting/105/agenda.html.

Bruno and I would like to ask folks to send requests for presentation slots in 
the SPRING meeting. Please indicate:

  *   the name of the draft you'd like to present,
  *   the speaker's name,
  *   the amount of time you would like to be allotted - this should cover 
*both* your presentation and discussion.
If you're planning to present a new non-working group draft, please first post 
it to the list. If you're presenting an update to an existing draft, please 
send an update mail to the list -- preferably highlighting the changes that 
you've made.

There's a handy check-list for presenting at a SPRING meeting on the 
wiki.

We are *always* oversubscribed on meeting agenda slots -- please consider 
carefully whether there are items in your update that really benefit from 
face-to-face discussion. If the draft has simply been refreshed since last time 
it was presented, with no material changes, please consider not requesting a 
slot to make our lives easier!

Please have your requests to us by 17:00 PDT on July 8th. We'd like your slides 
Monday July 22nd at 10:00 EST at the very latest to give us time to be able to 
put together the materials for remote participants.

Thanks,
Rob & Bruno,

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

Re: [spring] WG Adoption Call: draft-guichard-spring-nsh-sr

[Linda Dunbar]

Rob,

I support adoption.

Linda Dunbar

On Thu, Jun 27, 2019 at 2:14 AM Rob Shakir 
mailto:40google@dmarc.ietf.org>> wrote:
Hi SPRING WG,

This email initiates a two week working group adoption call for 
draft-guichard-spring-nsh-sr. 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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2Fsearch%2F%3Fsubmit%3Ddraft%26id%3Ddraft-guichard-spring-nsh-sr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Caf51628e22b8462525e508d6fb2742c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972543378589074&sdata=x5h2m8umdm%2BJcdx%2FpIOJbVykTo0DuiowI20TFQ9SfHs%3D&reserved=0>.

Thanks!
Rob & Bruno.


___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Caf51628e22b8462525e508d6fb2742c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972543378599065&sdata=O7pSmiVp%2BKvcABD%2FD3IpgMi11vPcMpANdOojcb7RAyA%3D&reserved=0>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Linda Dunbar]

Support,

Linda Dunbar


From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Rob Shakir
Sent: Thursday, June 27, 2019 2:14 AM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] WG Adoption Call: draft-xuclad-spring-sr-service-programming

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<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2Fsearch%2F%3Fsubmit%3Ddraft%26id%3Ddraft-xuclad-spring-sr-service-programming&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C671e029aae1949ec3e6908d6fafa5ddb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972350566112829&sdata=ICkg4uNn5XUSdkJX0vUmQ2YvTkicYUKX7IXxzrpN6bw%3D&reserved=0>.

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

[Linda Dunbar]

Support,

Linda Dunbar


On Thu, Mar 14, 2019 at 3:50 AM 
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] IETF 104 - SPRING meeting

[Linda Dunbar]

Bruno, 

Sorry for the late request, possible to add 5 minutes for the update to the 
following draft? 

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/

Thank you, 

Linda Dunbar

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Friday, March 15, 2019 12:16 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] IETF 104 - SPRING meeting

Hi SPRING WG,
 
The agenda for the SPRING working group session at IETF 104 has been uploaded to
https://datatracker.ietf.org/meeting/104/materials/agenda-104-spring-00

We were oversubscribed for this session.
Whether your draft made it to the agenda or not, you are invited to introduce 
your draft/update to the mailing list.

Please send your slides to both chairs before Tuesday, March 26, 13:00 local 
time. Earlier is better. Sending PDF is usually better (than the automatic 
conversion).
A checklist is available on the wiki: 
https://trac.ietf.org/trac/spring/wiki/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting

Thank you,

See you in Prague.
--Rob, Bruno

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Monday, March 4, 2019 5:55 PM
To: SPRING WG
Cc: spring-cha...@ietf.org
Subject: [spring] IETF 104 - SPRING meeting

Hi WG,

For IETF 104, the SPRING WG is currently scheduled to meet Thursday, March 28, 
13:50-15:50. We have a two hours session.
https://datatracker.ietf.org/meeting/104/agenda.html

It is time to start building the SPRING WG agenda.

Please send to chairs your request for a presentation slot, indicating draft 
name, speaker, and desired duration (covering presentation and discussion), 
before Monday 2019-03-11 COB. Before is better.

If it is the first presentation of a non-WG draft, please first introduce your 
draft on the mailing list.
Otherwise, please give a reason why it is required to have a new presentation 
slot.

A checklist is available on the wiki: 
https://trac.ietf.org/trac/spring/wiki/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting

Please send your slides before Tuesday, March 26, 13:00 local time. Earlier is 
better.

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

_

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

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

[spring] Secdir last call review of draft-ietf-spring-segment-routing-mpls-18

[Linda Dunbar]

Reviewer: Linda Dunbar
Review result: Ready

Reviewer: Linda Dunbar
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The document provides the detailed explanation of SR-MPLS processing in
addition to RFC 8402. Since SR-MPLS are in the trusted domain, it is assumed
that there is no malicious attacks to the nodes for the data plane and control
plane.  RFC8402 already has the good description on the Security Consideration
for both SR-MPLS & SRv6.

Linda Dunbar

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

Re: [spring] Working Group Adoption Call for draft-cheng-spring-mpls-path-segment

[Linda Dunbar]

Support, 

Linda Dunbar



On 2019-02-20, 4:01 AM, "bruno.decra...@orange.com"  
wrote:

Hi SPRING WG,

This email initiates a two week call for working group adoption for 
draft-cheng-spring-mpls-path-segment.

Please indicate your support, comments, or objection, for adopting this 
draft as a working group item by March 6th 2019.
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.

Additionally, there are currently 7 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 authors and contributors to confirm their IPR 
position on this document.

(1) https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment

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

___
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] to progress draft-cheng-spring-mpls-path-segment

[Linda Dunbar]

Support, 

Linda Dunbar

-Original Message-
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, February 13, 2019 5:48 AM
To: Loa Andersson ; spring@ietf.org; 
draft-cheng-spring-mpls-path-segm...@ietf.org
Subject: Re: [spring] to progress draft-cheng-spring-mpls-path-segment

I have just read the draft and agree that it should be adopted by the WG. It 
solves an important problem in instrumenting and protecting an SR path.

It should be noted that we needed to do something very similar in mainstream 
MPLS via the synonymous label work which is already adopted. 
However SL did not address the SR case. We therefore need this path label work 
to be progressed.

- Stewart

On 10/02/2019 08:11, Loa Andersson wrote:
> Working Group,
>
> I have reviewed draft-cheng-spring-mpls-path-segment and as far as I 
> can see, it is ready for wg adoption.
>
> There were some comments in Bangkok, but due to the many collisions 
> between working groups at that meeting I couldn't attend the SPRING 
> f2f.
>
> The minutes are not clear, but as far as I understand, there is 
> nothing that can't be resolved in the wg process.
>
> /Loa

___
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

[spring] some comments to draft-filsfils-spring-srv6-network-programming-05

[Linda Dunbar]

Clarence, et al,

Does your draft cover the scenario of a node "N"  in Section 5 (Transit 
Behavior) belonging to a different administrative domain?

Section 7 is on Intra Domain deployment Basic Security, will you consider 
"Inter Domain" basic security?

I assume that "SEC 1", "SEC 2" etc. are meant for Identifying "Basic Security". 
Can you use a "SEC-1", or "SEC-REQ-1", etc. to make it easier for cross 
reference from other documents?

Thanks, Linda Dunbar
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] IETF 102 - SPRING meeting: reasons for a presentation slot for SR-SD-WAN-Over-Hybrid Networks

[Linda Dunbar]

Bruno,

Understand that there will be tight agenda for the upcoming SPRING WG session 
in IETF102. We sent the request for presentation slot back in June 19, but 
didn't explain why we need the meeting face to face time. Here are why:


-The draft is for the SPRING charter bullet of Interworking between SR 
& Existing Networks. It describes a method for end-to-end (E2E) SD-WAN paths 
(most likely encrypted) to traverse specific list of network segments, some of 
which are SR enabled and others may be IP networks that do not support SR, to 
achieve the desired optimal E2E quality.

-There have been a lot of discussion on the SPRING mailing list for the 
draft. We would like to summary the discussion at the meeting time.


Thank you very much.

Linda Dunbar

From: Linda Dunbar
Sent: Tuesday, June 19, 2018 6:06 PM
To: bruno.decra...@orange.com; spring@ietf.org
Subject: RE: IETF 102 - SPRING meeting


Hi Bruno,

I would like to get a 10 minute slot to present   
https://www.ietf.org/internet-drafts/draft-dunbar-sr-sdwan-over-hybrid-networks-01.txt

Speaker will be myself.

Thanks!

Linda Dunbar

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Monday, June 18, 2018 6:30 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] IETF 102 - SPRING meeting


Hi all,



During IETF 102, the SPRING WG is currently scheduled to meet Monday 
13:30-15:30. We have a two hours session.
https://datatracker.ietf.org/meeting/102/agenda.html


It is time start building the SPRING WG agenda for Montreal.

Please send your request for a presentation slot, indicating draft name, 
speaker, and desired duration (covering presentation and discussion), before 
Monday 2018-07-02  09:00 CET. Before is better.

If it is not the first presentation of a non-WG draft, please give a reason why 
it is required to have a new presentation slot.

A checklist is available on the wiki: 
https://trac.ietf.org/trac/spring/wiki/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting



As we are meeting on Monday, please send your slides on time, before Sunday 
18:00 local time. Earlier is better.


Thanks,
--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] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

[Linda Dunbar]

Just one more point about using SR’s traffic steering capability described in 
our draft:
when traffic between two end points (E1<-> E2) traverse a SR domain and there 
are multiple egress PEs (PE-a, PE-b, etc) to reach E2, it is relatively easy 
for SR to steer some flows towards egress PE-a and other flows towards egress 
PE-b.

Linda Dunbar

From: Linda Dunbar
Sent: Tuesday, July 03, 2018 3:09 PM
To: 'Robert Raszuk' ; Jeff Tantsura 
Cc: SPRING WG List 
Subject: RE: [spring] solicit feedback on 
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node 
using UDP port to indicate to SR ingress node how to map to appropriate Binding 
SID

Robert, Jeff, Sasha, Jim, Lou, et al,

Thank you very much for the feedback. The main attraction of SR is indeed its 
Traffic steering capability, especially when there are multiple egress PEs to 
reach the SD-WAN end points. SR can easily force a path to traverse the 
explicitly selected egress node or explicit segments through the SR Domain 
based on the applications need.

If only using MPLS, quite some configurations are needed to force a flow to a 
specific egress PE.

Linda


From: rras...@gmail.com<mailto:rras...@gmail.com> [mailto:rras...@gmail.com] On 
Behalf Of Robert Raszuk
Sent: Tuesday, July 03, 2018 3:08 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Cc: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] solicit feedback on 
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node 
using UDP port to indicate to SR ingress node how to map to appropriate Binding 
SID

Hello Jeff,

“What exactly do you call by "resource allocation" in WAN ?” – anything that is 
not “best effort”, BW reservation, protection type, number of hops, latency, 
you name it…

Somehow, between ATM and now
​​
we managed to build a technology that would work in both, control and data 
planes 😉
TE with BW reservation is a working technology, with all the bugs, whether done 
as a soft state on a device and enforced in FW, aka RSVP-TE or computed on a 
controller and enforced by policing configuration out of band. We also know 
pretty well how to compute a constrain path that is loop free and with the 
constrains. Either way, working stuff.


​It has been nearly 20 years and it seems that some marketing slides from 
vendors are still in minds of many many people ...

MPLS-TE does *NOT* do any data plane reservations nor any data plane resource 
allocation. It is all control plane game. Let me shock you even more today ... 
what we call "Guaranteed Bandwidth TE" also does *NOT* perform any data plane 
reservations. This up to current days is the most misunderstood element (or 
hidden secret) of one of the technologies which has been made available during 
the last two decades.

If you signal MPLS TE LSP with 5M "reservation" to check if such a path in your 
network can be established such check is *ONLY* done at the control plane 
(RP/RE) pools of available bandwidth (per priority level) registers and 
physical interfaces nor any data plane queues are never aware of it.

Now what is a direct consequence of this is if you like to really do control 
plane reservations and think of it as actual data plane you must do it in 1:1 
fashion - again all done in control plane. That means that two fundamental 
conditions must be met:

A) All traffic must be sent over MPLS-LSPs - be it IPv4, IPv6, multicast etc 
... - even if I have seen 3 networks trying to do that for IPv4 no one did it 
for all traffic types.

B) All traffic entering your network must be subject to very strict admission 
control and excess shaped or dropped which is very hard thing to do considering 
statistical multiplexing gains you count on in any IP network (Explanation: On 
any single ingress node you must apply strict CAC as you are not aware about 
what traffic is coming from other ingress nodes. So you may be dropping or 
shaping traffic which could flow through your network just fine end to end due 
to absence of competing class from different ingress).
​
​All RSVP-TE does is traffic steering in normal steady state or during 
protection. That's all. In the WAN's data plane it is all back to basic Diff 
Serve at each router's data plane.

The only technology which does provide interface data plane reservation is RSVP 
IntServ - but I doubt anyone here or Linda in her draft meant to use such tool.

Why am I jumping on this here in SPRING WG list ... Well few months ago I have 
witnessed a discussion where someone was arguing that SR is much worse then 
MPLS-TE as it does not provide any data plane reservations. When I tried to 
nicely and politely explain how confused the person is the look I got was 
comparable to those green folks walking down from just arrived UFO.

So to conclude SR just like MPLS-TE does a good job in packet stee

Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

[Linda Dunbar]

Robert, Jeff, Sasha, Jim, Lou, et al,

Thank you very much for the feedback. The main attraction of SR is indeed its 
Traffic steering capability, especially when there are multiple egress PEs to 
reach the SD-WAN end points. SR can easily force a path to traverse the 
explicitly selected egress node or explicit segments through the SR Domain 
based on the applications need.

If only using MPLS, quite some configurations are needed to force a flow to a 
specific egress PE.

Linda


From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Tuesday, July 03, 2018 3:08 AM
To: Jeff Tantsura 
Cc: Linda Dunbar ; SPRING WG List 
Subject: Re: [spring] solicit feedback on 
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node 
using UDP port to indicate to SR ingress node how to map to appropriate Binding 
SID

Hello Jeff,

“What exactly do you call by "resource allocation" in WAN ?” – anything that is 
not “best effort”, BW reservation, protection type, number of hops, latency, 
you name it…

Somehow, between ATM and now
​​
we managed to build a technology that would work in both, control and data 
planes 😉
TE with BW reservation is a working technology, with all the bugs, whether done 
as a soft state on a device and enforced in FW, aka RSVP-TE or computed on a 
controller and enforced by policing configuration out of band. We also know 
pretty well how to compute a constrain path that is loop free and with the 
constrains. Either way, working stuff.


​It has been nearly 20 years and it seems that some marketing slides from 
vendors are still in minds of many many people ...

MPLS-TE does *NOT* do any data plane reservations nor any data plane resource 
allocation. It is all control plane game. Let me shock you even more today ... 
what we call "Guaranteed Bandwidth TE" also does *NOT* perform any data plane 
reservations. This up to current days is the most misunderstood element (or 
hidden secret) of one of the technologies which has been made available during 
the last two decades.

If you signal MPLS TE LSP with 5M "reservation" to check if such a path in your 
network can be established such check is *ONLY* done at the control plane 
(RP/RE) pools of available bandwidth (per priority level) registers and 
physical interfaces nor any data plane queues are never aware of it.

Now what is a direct consequence of this is if you like to really do control 
plane reservations and think of it as actual data plane you must do it in 1:1 
fashion - again all done in control plane. That means that two fundamental 
conditions must be met:

A) All traffic must be sent over MPLS-LSPs - be it IPv4, IPv6, multicast etc 
... - even if I have seen 3 networks trying to do that for IPv4 no one did it 
for all traffic types.

B) All traffic entering your network must be subject to very strict admission 
control and excess shaped or dropped which is very hard thing to do considering 
statistical multiplexing gains you count on in any IP network (Explanation: On 
any single ingress node you must apply strict CAC as you are not aware about 
what traffic is coming from other ingress nodes. So you may be dropping or 
shaping traffic which could flow through your network just fine end to end due 
to absence of competing class from different ingress).
​
​All RSVP-TE does is traffic steering in normal steady state or during 
protection. That's all. In the WAN's data plane it is all back to basic Diff 
Serve at each router's data plane.

The only technology which does provide interface data plane reservation is RSVP 
IntServ - but I doubt anyone here or Linda in her draft meant to use such tool.

Why am I jumping on this here in SPRING WG list ... Well few months ago I have 
witnessed a discussion where someone was arguing that SR is much worse then 
MPLS-TE as it does not provide any data plane reservations. When I tried to 
nicely and politely explain how confused the person is the look I got was 
comparable to those green folks walking down from just arrived UFO.

So to conclude SR just like MPLS-TE does a good job in packet steering via your 
domain. (SR can do actually more via embedded functions/apps). But the 
fundamental difference is that SR does that steering without necessity of 
number of control plane protocols and their required extensions - so does 
simplify control plane significantly. Neither of those do any data plane 
reservations and all bandwidth contentions need to be resolved via classic QoS.

Cheers,
R.

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

Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

[Linda Dunbar]

Jeff,

Replies are inserted below:

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Monday, July 02, 2018 5:36 PM
To: Linda Dunbar ; Robert Raszuk 
Cc: SPRING WG List 
Subject: Re: [spring] solicit feedback on 
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node 
using UDP port to indicate to SR ingress node how to map to appropriate Binding 
SID

Hi Linda,

(not speaking as rtgwg chair, where you might want to present the draft)
[Linda] Yes, we have another draft describing the gap of existing protocols to 
address SD-WAN scenarios: 
https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/, which we 
would like to present to RTGwg as it touches protocols in several WGs.



The scenario we are talking about is really - WAN (underlay/transport) 
controller interworking with SD-WAN (overlay) controller.
[Linda] Yes.

Resource allocation could happen by either WAN controller pre-allocating 
resources and then exposing them to SD-WAN controller for consumption (ala 
carte) or SD-WAN controller asking for a particular set of resources (on 
demand) and WAN controller providing these. In any case – there’s business 
relationship between 2 or more parties, so from functionality prospective a 
node that is transit (not service aware) should forward the traffic based on 
the destination, while node that is service aware (BSID anchor) should pop 
IP/UDP and lookup the BSID/steer the traffic into SR policy, using SPRING lingo.
[Linda] The Resource management are completely within the operator’s domain. 
The draft is only to describe a way to force SD-WAN traffic to the selected 
Ingress PEs (and potentially the desired egress PEs). How those Ingress PEs and 
Egress PEs are selected is completely out of the scope of the draft.
The section 3.3 describes How & Why SR is useful for those use cases.


SRinUDP encap provides ability to traverse non SR /3rd party networks, BSID 
(has to be provided by WAN controller at the resource allocation time) is 
pushed by source SD-WAN node with the FEC that is associated with the 
particular behavior and hence doesn’t require any additional mapping, e.g BSID 
value is the mapping (BSID lookup yields an egress adj/tunnel)

[Linda] SRinUDP is another case (which hasn’t been discussed in the draft yet, 
should be added in the future). The draft currently only covers SD-WAN source 
node encapsulate some “Key” in the tunnel between SD-WAN source node and SR 
Ingress node, so that SR ingress node can map the flow to its desired Binding 
SID.

Hope this makes sense to you

[Linda] Absolutely. Thank you very much for the suggestion.

Cheers,
Jeff

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Linda Dunbar mailto:linda.dun...@huawei.com>>
Date: Monday, July 2, 2018 at 15:11
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] solicit feedback on 
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node 
using UDP port to indicate to SR ingress node how to map to appropriate Binding 
SID

Robert,

There are many definitions for SD-WAN in the industry. I used the one from 
ONUG, who claims that “SD-WAN” concept was created by them in 2013: 
https://www.onug.net/software-defined-wide-area-network-sd-wan/.

In terms of real time deployment, there are plenty. For example, here are some 
public available cases & services:
https://youtu.be/JRoTXMSxtCY;
http://www.verizonenterprise.com/products/networking/managed-network-services/managed-sdwan/
http://www.centurylink.com/business/networking/sd-wan.html

It is CPE pooling together paths from different ISPs.   The draft proposes a 
method for Service Provider to attract flows which would otherwise traverse 
public internet, to traverse its own domain.

Linda

From: rras...@gmail.com<mailto:rras...@gmail.com> [mailto:rras...@gmail.com] On 
Behalf Of Robert Raszuk
Sent: Monday, July 02, 2018 4:50 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] solicit feedback on 
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node 
using UDP port to indicate to SR ingress node how to map to appropriate Binding 
SID

Hi Linda,

You mentioned in the document the below quote:

   "SD-WAN, as described by ONUG (Open Network User Group), is about
   pooling WAN bandwidth from n service providers to get better WAN
   bandwidth management, visibility & control."

Can you provide some real life examples listing which service providers allow 
to be externally pooled for their available WAN bandwidth as well as what 
interface is used to get such pooling instantiated in place ?

Once we understand above next natural question would be to ask how accurate is 
such pooling in the light of the observation that due to basic characteristics 
of the service provider's traffic patterns availabl

[spring] Can we use "Interworking between SR and Existing Networks" wording in the Spring Charter? FW: Updating the SPRING WG Charter

[Linda Dunbar]

Martin,

The proposed SPRING charter has:
o Inter-working between SRv6 and SR-MPLS  and between SR and existing routing 
solutions to allow for seamless deployment and co-existence..

We think it should be:
o Inter-working between SRv6 and SR-MPLS and between SR and existing networks 
routing solutions to allow for seamless deployment and co-existence..
Because the term “routing solutions” is ambiguous and can mean different things 
to different people.
It is very likely that flows might traverse some existing networks (like IPv4) 
before reaching SR domain. After all, it is not likely to have all network to 
be SR from Day 1.

Bruno said “existing networks” vs “existing routing solutions” are equally 
good, and the charter wording is now at your hand.

We hope you can change the wording.

Thank you very much.

Linda Dunbar


From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Tuesday, July 03, 2018 2:40 AM
To: Linda Dunbar 
Cc: SPRING WG List ; Jeff Tantsura 
Subject: RE: [spring] Updating the SPRING WG Charter

Linda,

Thanks for your review of the charter.

> From: Linda Dunbar [mailto:linda.dun...@huawei.com]
> IMHO, “Interworking between SR and Legacy Networks” is more appropriate than 
> “Interworking between SR and existing routing solutions” because 
> “Interworking SR with existing routing solutions” can imply needing changes 
> to the “existing routing solutions”.

I’d favor “existing” for the following reasons:
- I’m not sure that Legacy is a well-defined term, nor that it is a binary 
condition
- I’d rather avoid a discussion about a technology been legacy. IMO, SR-LDP 
interwork is useful to incrementally deploy SR in existing LDP networks. And 
I’m happy to avoid discussionss about LDP been legacy or not.
- In the end, the goal is to introduce SR in existing networks (in addition to 
Greenfield deployments)
- I think that’s the option to modify existing routing solutions is a feature 
rather than a bug. If existing routing solutions may be modified, and if this 
is the easier/best path, I don’t think we should rule it out.


> How about “Interworking SR with existing networks”?
Regarding: “existing networks” vs “existing routing solutions”
Both equally works for me.
As the charter has now been sent to IESG, this is currently in Martin’s hand.

Thanks,
--Bruno

From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Friday, June 29, 2018 5:26 PM
To: Jeff Tantsura; DECRAENE Bruno IMT/OLN
Cc: SPRING WG List
Subject: RE: [spring] Updating the SPRING WG Charter

How about “Interworking SR with existing networks”?

Linda

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Friday, June 29, 2018 10:20 AM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Linda,

“Legacy Networks” is a derogatory term used by OF bigots to call anything, 
that’s  distributed ☺
There’s nothing wrong with changing and evolving existing networking to be more 
programmable and flexible, changes are welcome.

I don’t think we should call existing networking – “Legacy”.

Cheers,
Jeff
From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Linda Dunbar mailto:linda.dun...@huawei.com>>
Date: Friday, June 29, 2018 at 11:05
To: "bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>" 
mailto:bruno.decra...@orange.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Bruno,

IMHO, “Interworking between SR and Legacy Networks” is more appropriate than 
“Interworking between SR and existing routing solutions” because “Interworking 
SR with existing routing solutions” can imply needing changes to the “existing 
routing solutions”.

Linda


From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
[mailto:bruno.decra...@orange.com]
Sent: Friday, June 29, 2018 8:56 AM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: RE: [spring] Updating the SPRING WG Charter

Linda,

Thanks for the feedback.
Please see inline [Bruno]

From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Thursday, June 28, 2018 6:18 PM
To: DECRAENE Bruno IMT/OLN; SPRING WG List
Subject: RE: [spring] Updating the SPRING WG Charter

Bruno,

Many thanks for the updated charter. All look good except one minor wording 
change for the bullet:

You have:
o Inter-working between SRv6 and SR-MPLS  and between SR and existing routing 
solutions to allow for seamless deployment and co-existence..

We think it should be:
o Inter-working between SRv6 and SR-MPLS/LegacyNetwork  and between SR and 
existing routing solutions to allow for seamless deployment and co-existence..

Because it is very likely that flows might traverse some segment of legacy 
network (like IPv4) befor

Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

[Linda Dunbar]

Robert,

There are many definitions for SD-WAN in the industry. I used the one from 
ONUG, who claims that “SD-WAN” concept was created by them in 2013: 
https://www.onug.net/software-defined-wide-area-network-sd-wan/.

In terms of real time deployment, there are plenty. For example, here are some 
public available cases & services:
https://youtu.be/JRoTXMSxtCY;
http://www.verizonenterprise.com/products/networking/managed-network-services/managed-sdwan/
http://www.centurylink.com/business/networking/sd-wan.html

It is CPE pooling together paths from different ISPs.   The draft proposes a 
method for Service Provider to attract flows which would otherwise traverse 
public internet, to traverse its own domain.

Linda

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Monday, July 02, 2018 4:50 PM
To: Linda Dunbar 
Cc: SPRING WG List 
Subject: Re: [spring] solicit feedback on 
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node 
using UDP port to indicate to SR ingress node how to map to appropriate Binding 
SID

Hi Linda,

You mentioned in the document the below quote:

   "SD-WAN, as described by ONUG (Open Network User Group), is about
   pooling WAN bandwidth from n service providers to get better WAN
   bandwidth management, visibility & control."

Can you provide some real life examples listing which service providers allow 
to be externally pooled for their available WAN bandwidth as well as what 
interface is used to get such pooling instantiated in place ?

Once we understand above next natural question would be to ask how accurate is 
such pooling in the light of the observation that due to basic characteristics 
of the service provider's traffic patterns available bandwidth or in other 
words congestion usually have very transient nature ?

If I were writing such document I would give up any pooling and instead use one 
of many available techniques to measure the end to end path quality when making 
at the ingress the decision of the preferred path to be taken. That is in fact 
what number of SD-WANs today already do without any need to  make any attempts 
to enforce anything at the ingress to the transit journey :).

Many thx,
Robert.



On Mon, Jul 2, 2018 at 11:33 PM, Linda Dunbar 
mailto:linda.dun...@huawei.com>> wrote:
https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ 
describes a method for end-to-end (E2E) SD-WAN paths (most likely encrypted) to 
traverse specific list of network segments, some of which are SR enabled and 
others may be IP networks that do not support SR, to achieve the desired 
optimal E2E quality.
In another word, one or both SD-WAN end points are NOT directly attached to SR 
PE nodes.

Under many circumstances the SR's Binding SID can't be exposed to the SD-WAN 
source node (e.g. if the SD-WAN source node belongs to a different 
administrator than the one who manage/own the SR domain).

The draft propose a method for SR Controller to expose a "Key" to the SD-WAN 
source node. The SR Ingress node will map the "Key" carried by the SD-WAN 
traffic/flows to their designated Binding SID.
The "Key" can be carried by GRE key field, or be encoded as UDP Source Port 
used by SD-WAN source node to differentiate flows.

We understand that UDP source port is usually used for Entropy purpose.

We want to hear feedback, flaws or allergic reaction to our proposed method for 
some deployment scenarios like:
  1) only one or two 3rd party hops are between SD-WAN end points and PE and 
those hops may not even use Entropy (like LTE links); or
  2) Grouping Applications by UDP ports may enforce same application traverse 
through same route, which is acceptable by many deployment scenarios).

Thank you very much.

Linda Dunbar

___
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

[spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID

[Linda Dunbar]

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ 
describes a method for end-to-end (E2E) SD-WAN paths (most likely encrypted) to 
traverse specific list of network segments, some of which are SR enabled and 
others may be IP networks that do not support SR, to achieve the desired 
optimal E2E quality. 
In another word, one or both SD-WAN end points are NOT directly attached to SR 
PE nodes. 

Under many circumstances the SR's Binding SID can't be exposed to the SD-WAN 
source node (e.g. if the SD-WAN source node belongs to a different 
administrator than the one who manage/own the SR domain). 

The draft propose a method for SR Controller to expose a "Key" to the SD-WAN 
source node. The SR Ingress node will map the "Key" carried by the SD-WAN 
traffic/flows to their designated Binding SID. 
The "Key" can be carried by GRE key field, or be encoded as UDP Source Port 
used by SD-WAN source node to differentiate flows. 

We understand that UDP source port is usually used for Entropy purpose. 

We want to hear feedback, flaws or allergic reaction to our proposed method for 
some deployment scenarios like: 
  1) only one or two 3rd party hops are between SD-WAN end points and PE and 
those hops may not even use Entropy (like LTE links); or 
  2) Grouping Applications by UDP ports may enforce same application traverse 
through same route, which is acceptable by many deployment scenarios).

Thank you very much. 

Linda Dunbar

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

Re: [spring] Updating the SPRING WG Charter

[Linda Dunbar]

How about “Interworking SR with existing networks”?

Linda

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Friday, June 29, 2018 10:20 AM
To: Linda Dunbar ; bruno.decra...@orange.com
Cc: SPRING WG List 
Subject: Re: [spring] Updating the SPRING WG Charter

Linda,

“Legacy Networks” is a derogatory term used by OF bigots to call anything, 
that’s  distributed ☺
There’s nothing wrong with changing and evolving existing networking to be more 
programmable and flexible, changes are welcome.

I don’t think we should call existing networking – “Legacy”.

Cheers,
Jeff
From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Linda Dunbar mailto:linda.dun...@huawei.com>>
Date: Friday, June 29, 2018 at 11:05
To: "bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>" 
mailto:bruno.decra...@orange.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Bruno,

IMHO, “Interworking between SR and Legacy Networks” is more appropriate than 
“Interworking between SR and existing routing solutions” because “Interworking 
SR with existing routing solutions” can imply needing changes to the “existing 
routing solutions”.

Linda


From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
[mailto:bruno.decra...@orange.com]
Sent: Friday, June 29, 2018 8:56 AM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>
Subject: RE: [spring] Updating the SPRING WG Charter

Linda,

Thanks for the feedback.
Please see inline [Bruno]

From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Thursday, June 28, 2018 6:18 PM
To: DECRAENE Bruno IMT/OLN; SPRING WG List
Subject: RE: [spring] Updating the SPRING WG Charter

Bruno,

Many thanks for the updated charter. All look good except one minor wording 
change for the bullet:

You have:
o Inter-working between SRv6 and SR-MPLS  and between SR and existing routing 
solutions to allow for seamless deployment and co-existence..

We think it should be:
o Inter-working between SRv6 and SR-MPLS/LegacyNetwork  and between SR and 
existing routing solutions to allow for seamless deployment and co-existence..

Because it is very likely that flows might traverse some segment of legacy 
network (like IPv4) before reaching SRv6 domain. After all, it is not like to 
expect all network to be IPv6 from Day 1.

[Bruno] I though this point would be covered by Inter-working […] between SR 
and existing routing solutions to allow for seamless deployment and co-existence
Am I missing something? Or would you have something specific in mind?

--Bruno

Sincerely hope you can add those minor wording to the bullet.

Linda Dunbar


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Thursday, June 28, 2018 7:52 AM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

Following the discussion on the mailing list, please find below the updated 
text.
The plan is to send it to Martin end of this week.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of 
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as 
a forum to discuss SPRING networks operations, define new applications, and 
specify extensions of Segment Routing technologies.

The SPRING WG defines procedures that allow a node to steer a packet through an 
SR Policy instantiated as an ordered list of instructions called segments and 
without the need for per-path state information to be held at transit nodes. 
Full explicit control (through loose or strict path specification) can be 
achieved in a network comprising only SPRING nodes, however SPRING nodes must 
inter-operate through loose routing in existing networks and may find it 
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and 
multi-AS environments. Segment Routing operates within a trusted domain; as 
described in the architecture, a node imposing a segment list is assumed to be 
allowed to do so. Nonetheless, the SPRING WG must strive to identify and 
address security considerations brought up by the technologies it defines.
The technologies SPRING WG defines may be applicable to both centralised and 
distributed path computation.

SPRING WG should avoid modification to existing data planes that would make 
them incompatible with existing deployments. Where possible, existing control 
and management plane protocols must be used within existing architectures to 
implement the SPRING function. Any modification of -or extension to- existing 
architectures, data planes, or control or management plane protocols should be 
carried out in the WGs responsible for the architecture, data plane, or control 
or management plane protocol being modifie

Re: [spring] Updating the SPRING WG Charter

[Linda Dunbar]

Bruno,

IMHO, “Interworking between SR and Legacy Networks” is more appropriate than 
“Interworking between SR and existing routing solutions” because “Interworking 
SR with existing routing solutions” can imply needing changes to the “existing 
routing solutions”.

Linda


From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
Sent: Friday, June 29, 2018 8:56 AM
To: Linda Dunbar 
Cc: SPRING WG List 
Subject: RE: [spring] Updating the SPRING WG Charter

Linda,

Thanks for the feedback.
Please see inline [Bruno]

From: Linda Dunbar [mailto:linda.dun...@huawei.com]
Sent: Thursday, June 28, 2018 6:18 PM
To: DECRAENE Bruno IMT/OLN; SPRING WG List
Subject: RE: [spring] Updating the SPRING WG Charter

Bruno,

Many thanks for the updated charter. All look good except one minor wording 
change for the bullet:

You have:
o Inter-working between SRv6 and SR-MPLS  and between SR and existing routing 
solutions to allow for seamless deployment and co-existence..

We think it should be:
o Inter-working between SRv6 and SR-MPLS/LegacyNetwork  and between SR and 
existing routing solutions to allow for seamless deployment and co-existence..

Because it is very likely that flows might traverse some segment of legacy 
network (like IPv4) before reaching SRv6 domain. After all, it is not like to 
expect all network to be IPv6 from Day 1.

[Bruno] I though this point would be covered by Inter-working […] between SR 
and existing routing solutions to allow for seamless deployment and co-existence
Am I missing something? Or would you have something specific in mind?

--Bruno

Sincerely hope you can add those minor wording to the bullet.

Linda Dunbar


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Thursday, June 28, 2018 7:52 AM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

Following the discussion on the mailing list, please find below the updated 
text.
The plan is to send it to Martin end of this week.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of 
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as 
a forum to discuss SPRING networks operations, define new applications, and 
specify extensions of Segment Routing technologies.

The SPRING WG defines procedures that allow a node to steer a packet through an 
SR Policy instantiated as an ordered list of instructions called segments and 
without the need for per-path state information to be held at transit nodes. 
Full explicit control (through loose or strict path specification) can be 
achieved in a network comprising only SPRING nodes, however SPRING nodes must 
inter-operate through loose routing in existing networks and may find it 
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and 
multi-AS environments. Segment Routing operates within a trusted domain; as 
described in the architecture, a node imposing a segment list is assumed to be 
allowed to do so. Nonetheless, the SPRING WG must strive to identify and 
address security considerations brought up by the technologies it defines.
The technologies SPRING WG defines may be applicable to both centralised and 
distributed path computation.

SPRING WG should avoid modification to existing data planes that would make 
them incompatible with existing deployments. Where possible, existing control 
and management plane protocols must be used within existing architectures to 
implement the SPRING function. Any modification of -or extension to- existing 
architectures, data planes, or control or management plane protocols should be 
carried out in the WGs responsible for the architecture, data plane, or control 
or management plane protocol being modified and in
coordination with the SPRING WG, but may be done in SPRING WG after agreement 
with all the relevant WG chairs and responsible Area Directors.


The SPRING WG will manage its specific work items by milestones agreed with the 
responsible Area Director.

The work-items of the SPRING WG include functional specifications for:
o Segment Routing policies and the associated steering, signalling and traffic 
engineering mechanisms.

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

o SRv6 network programming for the underlay networks and overlay services, and 
including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in 
networks with SR-MPLS and SRv6 data planes in the case where SR introduces 
specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 
data planes in the case where SR introduces specificities compared to MPLS or 
IPv6 technologies.

o Inter-working between

Re: [spring] Updating the SPRING WG Charter

[Linda Dunbar]

Bruno,

Many thanks for the updated charter. All look good except one minor wording 
change for the bullet:

You have:
o Inter-working between SRv6 and SR-MPLS  and between SR and existing routing 
solutions to allow for seamless deployment and co-existence..

We think it should be:
o Inter-working between SRv6 and SR-MPLS/LegacyNetwork  and between SR and 
existing routing solutions to allow for seamless deployment and co-existence..

Because it is very likely that flows might traverse some segment of legacy 
network (like IPv4) before reaching SRv6 domain. After all, it is not like to 
expect all network to be IPv6 from Day 1.

Sincerely hope you can add those minor wording to the bullet.

Linda Dunbar


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, June 28, 2018 7:52 AM
To: SPRING WG List 
Subject: Re: [spring] Updating the SPRING WG Charter

Hi SPRING,

Following the discussion on the mailing list, please find below the updated 
text.
The plan is to send it to Martin end of this week.

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of 
Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as 
a forum to discuss SPRING networks operations, define new applications, and 
specify extensions of Segment Routing technologies.

The SPRING WG defines procedures that allow a node to steer a packet through an 
SR Policy instantiated as an ordered list of instructions called segments and 
without the need for per-path state information to be held at transit nodes. 
Full explicit control (through loose or strict path specification) can be 
achieved in a network comprising only SPRING nodes, however SPRING nodes must 
inter-operate through loose routing in existing networks and may find it 
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and 
multi-AS environments. Segment Routing operates within a trusted domain; as 
described in the architecture, a node imposing a segment list is assumed to be 
allowed to do so. Nonetheless, the SPRING WG must strive to identify and 
address security considerations brought up by the technologies it defines.
The technologies SPRING WG defines may be applicable to both centralised and 
distributed path computation.

SPRING WG should avoid modification to existing data planes that would make 
them incompatible with existing deployments. Where possible, existing control 
and management plane protocols must be used within existing architectures to 
implement the SPRING function. Any modification of -or extension to- existing 
architectures, data planes, or control or management plane protocols should be 
carried out in the WGs responsible for the architecture, data plane, or control 
or management plane protocol being modified and in
coordination with the SPRING WG, but may be done in SPRING WG after agreement 
with all the relevant WG chairs and responsible Area Directors.


The SPRING WG will manage its specific work items by milestones agreed with the 
responsible Area Director.

The work-items of the SPRING WG include functional specifications for:
o Segment Routing policies and the associated steering, signalling and traffic 
engineering mechanisms.

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

o SRv6 network programming for the underlay networks and overlay services, and 
including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in 
networks with SR-MPLS and SRv6 data planes in the case where SR introduces 
specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 
data planes in the case where SR introduces specificities compared to MPLS or 
IPv6 technologies.

o Inter-working between SRv6 and SR-MPLS  and between SR and existing routing 
solutions to allow for seamless deployment and co-existence..

o new types of segments mapping to forwarding behavior  (e.g. local ingress 
replication, local forwarding resources, a pre-existing replication structure) 
if needed for new usages.

Any of the above may require architectural extensions.

The work-items of SPRING WG also include:
o Specification of management models (YANG) for Segment Routing applications, 
services and networks with SR-MPLS and SRv6 dataplanes.

The SPRING WG will coordinate and collaborate with other WGs as needed. Specific
expected interactions include (but may not be limited to):
* mpls on the MPLS dataplane and OAM extensions,
* 6man on the IPv6 dataplane for SR and associated OAM extensions
* lsr on OSPF and IS-IS extensions to flood SPRING-related information
* IDR for BGP extensions
* bess for VPN control plane
* pce on extensions to communicate with an external entity to compute and 
program SPRING

Re: [spring] IETF 102 - SPRING meeting

[Linda Dunbar]

Hi Bruno,

I would like to get a 10 minute slot to present   
https://www.ietf.org/internet-drafts/draft-dunbar-sr-sdwan-over-hybrid-networks-01.txt

Speaker will be myself.

Thanks!

Linda Dunbar

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Monday, June 18, 2018 6:30 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] IETF 102 - SPRING meeting


Hi all,



During IETF 102, the SPRING WG is currently scheduled to meet Monday 
13:30-15:30. We have a two hours session.
https://datatracker.ietf.org/meeting/102/agenda.html


It is time start building the SPRING WG agenda for Montreal.

Please send your request for a presentation slot, indicating draft name, 
speaker, and desired duration (covering presentation and discussion), before 
Monday 2018-07-02  09:00 CET. Before is better.

If it is not the first presentation of a non-WG draft, please give a reason why 
it is required to have a new presentation slot.

A checklist is available on the wiki: 
https://trac.ietf.org/trac/spring/wiki/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting



As we are meeting on Monday, please send your slides on time, before Sunday 
18:00 local time. Earlier is better.


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

[spring] Do you consider "steering large portion of a SD-WAN path over SR domain" as the "application" in the SPRING charter? RE: Updating the SPRING WG Charter

[Linda Dunbar]

Rob,

You said:
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.

Just want to make sure that I understand the term “define new applications” 
used in the SPRING charter wording:

We have a draft describing using SR to steer a SD-WAN path over desired network 
segments ( 
https://www.ietf.org/internet-drafts/draft-dunbar-sr-sdwan-over-hybrid-networks-01.txt
 ).  Will our draft be considered as the “new applications” in SPRING charter?


Thanks, Linda Dunbar.


From: Rob Shakir [mailto:ro...@google.com]
Sent: Sunday, June 03, 2018 4:32 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>
Cc: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
SPRING WG List mailto:spring@ietf.org>>
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

[spring] msg to SPRING to promote SR -SD WAN draft RE: Updating the SPRING WG Charter

[Linda Dunbar]

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.


From: Rob Shakir [mailto:ro...@google.com]
Sent: Sunday, June 03, 2018 4: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] Updating the SPRING WG Charter

[Linda Dunbar]

Hi Rob,

My suggestions (& comments) are inserted below.

Linda

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, June 01, 2018 11:44 AM
To: Rob Shakir ; SPRING WG List 

Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

Looks good, few additions, please see inline

Cheers,
Jeff
From: spring mailto:spring-boun...@ietf..org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Friday, June 1, 2018 at 09:05
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Updating the SPRING WG Charter

Hi SPRING,

After the discussions on the list and in London relating to the charter, Bruno 
and I have been working to propose a new charter for the WG with Martin, and 
the other routing ADs. The text for this suggested charter is below. We would 
like to solicit WG feedback on the charter text prior to Martin taking to the 
IESG. We'd like to try and get the charter agreed prior to IETF 102 in Montréal.

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?

The SPRING WG defines procedures that allow a node to steer a packet through an
SR Policy instantiated as an ordered list of instructions called segments and
without the need for per-path state information to be held at transit nodes.
Full explicit control (through loose or strict path specification) can be
achieved in a network comprising only SPRING nodes, however SPRING nodes must
inter-operate through loose routing in existing networks and may find it
advantageous to use loose routing for other network applications.

The scope of the SPRING WG work includes both single Autonomous System (AS) and
multi-AS environments. Segment Routing operates within a trusted domain; as
described in the architecture, a node imposing a segment list is assumed to be
allowed to do so. Nonetheless, the SPRING WG must strive to identify and
address security considerations brought up by the technologies it defines..  The
technologies SPRING WG defines may be applicable to both centralised and
distributed path computation.

SPRING WG should avoid modification to existing data planes that would make
them incompatible with existing deployments. Where possible, existing control
and management plane protocols must be used within existing architectures to
implement the SPRING function. Any modification of - or extension to - existing
architectures, data planes, or control or management plane protocols should be
carried out in the WGs responsible for the architecture, data plane, or control
or management plane protocol being modified and in coordination with the SPRING
WG, but may be done in SPRING WG after agreement with all the relevant WG
chairs and responsible Area Directors.


The SPRING WG will manage its specific work items by milestones agreed with the
responsible Area Director.

The work-items of the SPRING WG include functional specifications for:

o Segment Routing policies and the associated steering and traffic engineering
  mechanisms.

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)

o SRv6 network programming for the underlay networks and overlay services, and
  including data plane behavior and functions associated with SIDs

o Operation, Administration and Management (OAM), and traffic accounting in
  networks with SR-MPLS and SRv6 data planes in the case where SR introduces
  specificities compared to MPLS or IPv6 technologies.

o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6
  data planes in the case where SR introduces specificities compared to MPLS or
  IPv6 technologies.

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)

o Using SR
[jeff] SR conveyed metadata perhaps? Think of BSID x-connect into another layer
as the mechanism to identify sets of resources in networks with
  SR-MPLS and SRv6 dataplanes.

Any of the above may require architectural extensions.

The work-items of SPRING WG also include:

o Specification of management models (YANG) for Segment Routing applications,
  services and networks with SR-MPLS and SRv6 dataplanes.

The SPRING WG will coordinate and collaborate with other WGs as needed. Specific
expected interactions include (but may not be limited to):

 * mpls on the MPLS dataplane and OAM extensions,
 * 6man on the 

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

[Linda Dunbar]

I support the adoption of this document.

Best regards,
Linda Dunbar

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Wednesday, May 16, 2018 11:20 PM
To: SPRING WG List mailto:spring@ietf.org>>
Subject: [spring] Working Group Adoption Call for 
draft-filsfils-spring-segment-routing-policy

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] comments and suggestions to draft-ietf-spring-ipv6-use-cases-12

[Linda Dunbar]

Authors of draft-ietf-spring-ipv6-use-cases,

Section 2.3 SPRING in Data Center:
The current text in the section only describes why some DCs are transitioning 
from IPv4 to IPv6 natively, but not having very convincing points on why 
Segment Routing is needed (even with IPv6 addresses). Most data centers use 
private addresses, even AWS Cloud DCs use IP4.

I think the real use case of segment routing in Data Center (regardless IPv4 or 
IPv6 address space) is

-There could be very large number of parallel paths among leaf nodes 
(via Spine nodes). It is more efficient for leaf nodes to use designated (a set 
of) Spine nodes as outer destination addresses to avoid being placed on random 
paths (via ECMP) between leaf nodes and spine nodes.  The designated spine 
nodes can easily replace the outer destination address (i.e. the spine node 
address) with either Aggr nodes (going up) or the original leaf addresses 
(going down) .

Here is an old academic paper on why this approach is more effective in DC.

http://delivery.acm.org/10.1145/160/1592576/p51-greenberg.pdf?ip=12.111.81.80&id=1592576&acc=PUBLIC&key=5A3314F2D74B117C%2E5A3314F2D74B117C%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&__acm__=1519340096_d0ed599df20bcdcf17f61ce05325f3f2



Section 2.1 SPRING in the Small Office:

You stated that the IPv6 small office will have multiple egress points. Why? Is 
it because the small office is connected to multiple locations? How is it 
different from today's small office environment?

Don't most small offices have uplinks to one or two PEs?

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