Re: [spring] Updating the SPRING WG Charter

[bruno.decraene]

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

Re: [spring] Updating the SPRING WG Charter

[Jeff Tantsura]

Hi Bruno/Rob,

 

Looks good, well done!

 

Cheers,

Jeff

From: spring  on behalf of 
Date: Thursday, June 28, 2018 at 08:52
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 paths

* teas on generic traffic engineering architecture

* sfc on service chaining applications

* rtgwg on fast-reroute technologies

 

 

 

Thanks,

Rob, Bruno

 

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Friday, June 01, 2018 6:06 PM
To: SPRING WG List
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

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

[Jeff Tantsura]

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  on behalf of Linda Dunbar 

Date: Friday, June 29, 2018 at 11:05
To: "bruno.decra...@orange.com" 
Cc: SPRING WG List 
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] 
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
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.

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

[bruno.decraene]

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

Re: [spring] Updating the SPRING WG Charter

[bruno.decraene]

Hi Jie,

Thanks for the feedback.

Just for clarification, this work item allows for the definition of new type of 
segments, especially since the SPRING WG seems the right home to discuss this.
It’s not a statement that spray, or enhanced QoS/VPN, or any specific 
individual draft will be adopted by the WG.

Thanks,
Best regards,
--Bruno

From: Dongjie (Jimmy) [mailto:jie.d...@huawei.com]
Sent: Friday, June 29, 2018 10:33 AM
To: DECRAENE Bruno IMT/OLN; SPRING WG List
Subject: RE: [spring] Updating the SPRING WG Charter

Hi Bruno,

The updated charter text looks good to me. Thanks.

For the work item “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.”,  the enhanced VPN drafts has 
been proposed and discussed in previous meetings targeting at the requirements 
of network slicing, which is a widely accepted use case in many communities. 
Hope we could make good progress in this work item in SPRING.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, June 28, 2018 8:52 PM
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

Re: [spring] Updating the SPRING WG Charter

[Dongjie (Jimmy)]

Hi Bruno,

The updated charter text looks good to me. Thanks.

For the work item “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.”,  the enhanced VPN drafts has 
been proposed and discussed in previous meetings targeting at the requirements 
of network slicing, which is a widely accepted use case in many communities. 
Hope we could make good progress in this work item in SPRING.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, June 28, 2018 8:52 PM
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 paths
* teas on generic traffic engineering architecture
* sfc on service chaining applications
* rtgwg on fast-reroute technologies



Thanks,
Rob, Bruno

From: spring

Re: [spring] Updating the SPRING WG Charter

[Ruediger.Geib]

Hi Bruno,

thanks, looks good to me.

Regards, Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von 
bruno.decra...@orange.com
Gesendet: Donnerstag, 28. Juni 2018 14:52
An: SPRING WG List 
Betreff: 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 paths
* teas on generic traffic engineering architecture
* sfc on service chaining applications
* rtgwg on fast-reroute technologies



Thanks,
Rob, Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Friday, June 01, 2018 6:06 PM
To: SPRING WG List
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

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] Updating the SPRING WG Charter

[Alexander Vainshtein]

Bruno and all,
At the first glance looks just fine to me!

Thumb typed by Sasha Vainshtein


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

Sent: Thursday, June 28, 2018 3:51:43 PM
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 paths
* teas on generic traffic engineering architecture
* sfc on service chaining applications
* rtgwg on fast-reroute technologies



Thanks,
Rob, Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Friday, June 01, 2018 6:06 PM
To: SPRING WG List
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

Re: [spring] Updating the SPRING WG Charter

[bruno.decraene]

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 paths
* teas on generic traffic engineering architecture
* sfc on service chaining applications
* rtgwg on fast-reroute technologies



Thanks,
Rob, Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Friday, June 01, 2018 6:06 PM
To: SPRING WG List
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). SPRING WG serves as
a 

Re: [spring] Updating the SPRING WG Charter

[Stewart Bryant]

Hi Robert,

OK, so I understand this a bit more.

Yes, we could introduce a m/c tree in the middle of the network and have 
the leaves terminate in anything. That would include an SR unicast path 
and/or a new m/c tree or any combination thereof. What you have to do is 
to place the correct binding SID at the leaf of the tree which of course 
would be unique to that leaf, and identified by the m/c tree it arrived on.


So by adding in state through a generalised Binding SID mechanism we can 
build a full multicast system strictly within SR.


Sounds like it needs to be in charter.

- Stewart


On 19/06/2018 14:39, Robert Raszuk wrote:

Hi Stewart,

Nope that would be incorrect assumption.

Replication anchors would be where topologically it makes sense. And 
there may not be at all any multicast trees those subject flows would 
need to traverse. It is just about efficiency in content distribution.


Regards,
R.

On Tue, Jun 19, 2018 at 3:36 PM, Stewart Bryant 
mailto:stewart.bry...@gmail.com>> wrote:


For clarification:

Can I assume that we are talking about replication at ingress to a
series of  unicast SR paths each to an installed multicast tree
close to egress?

- Stewart


On 10/06/2018 10:58, Robert Raszuk wrote:

Hey Sasha,

100% agree with your last post. Very glad to see your support for
spray/fan-out or if you will
static MDTs to be in scope of SPRING.

Based on number of WG members input expressed both at the meeting
and on the list  I hope
proposed SPRING charter will be updated soon to reflect that.

Cheers,
R.

​PS. Btw - I am also ok that ingress replication is not relevant
to SPRING as it essentially happens at the
ingress to the domain. ​



On Sun, Jun 10, 2018 at 7:39 AM, Alexander Vainshtein
mailto:alexander.vainsht...@ecitele.com>> wrote:

Robert,

First of all, I did not say that your quote was inaccurate. I
apologize for possible misperception.

Second, I believe that spray or fan-out (meaning support of
externally computed static MDTs) in SR-MPLS is a relevant
focus area for the future WG work. Of course the solution
must be aligned with the SPRING and MPLS architecture, and
this imposes additional restrictions on how such a solution
would look.

Last but not least, I have differentiated (from my first
email on this thread) */ingress replication/* *in SR* from
the more generic *multicast support *in SR:

-The latter is quite acceptable to me

-The former, IMHO, should be left out of scope.

Hope this helps to clarify my position.

Regards, and, again, apologies for possible misinterpretation.

Sasha



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






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

Re: [spring] Updating the SPRING WG Charter

[Stewart Bryant]

Yes, I agree.

- S


On 19/06/2018 16:53, David Allan I wrote:


Hi

I do not quite get the same warm and fuzzy from the definition when 
thinking about multicast…..


The mapping of the binding SID to local policy is still IMO per path 
state. For a simple p2p path it is pretty straightforward as the 
mapping can be to a common policy abstraction at every node (send to 
‘x’) .


In the case of multicast, the mapping would be unique at every node 
that had state for the binding SID (send copy to ‘a’ and ‘b’, send 
copy to ‘m’ and ‘q’ etc.) .  So some means of disseminating the 
mappings is required, and correlating them with the SID.  So the 
difference between a binding SID and a global SID for multicast IMO is 
choice of terminology.


So you have to decide if the whole “avoiding per path state” 
discussion is simply a desirable goal, or a strict admonition.  A bulk 
overprovisioning model to eliminate per path state will not work for 
multicast.


Cheers

Dave

*From:*spring  *On Behalf Of *Alexander 
Vainshtein

*Sent:* Tuesday, June 19, 2018 6:38 AM
*To:* bruno.decra...@orange.com; Stewart Bryant 
*Cc:* SPRING WG List ; Rob Shakir 


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

Bruno, Stewart and all,

I have looked up Section 5 “*/Binding Segment/*” of the Segment 
Routing Architecture 
<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15>draft, 
and it says:


In order to provide greater scalability, network opacity, and service

independence, SR utilizes a Binding SID (BSID).  The BSID is bound to

an SR policy, instantiation of which may involve a list of SIDs.  Any

packets received with active segment = BSID are steered onto the

bound SR Policy.

A BSID may either be a local or a global SID.  If local, a BSID

SHOULD be allocated from the SRLB.  If global, a BSID MUST be

allocated from the SRGB.

Use of a BSID allows the instantiation of the policy (the SID list)

to be stored only on the node(s) which need to impose the policy.

Direction of traffic to a node supporting the policy then only

requires imposition of the BSID.  If the policy changes, this also

means that only the nodes imposing the policy need to be updated.

Users of the policy are not impacted.

From my POV this definition is fully aligned both with the Bruno’s 
last email and with my earlier argument why a BSID does not add a 
*/per-path state/* in the transit nodes.


Regards,

Sasha

Office: +972-39266302

Cell: +972-549266302

Email: alexander.vainsht...@ecitele.com 
<mailto:alexander.vainsht...@ecitele.com>


*From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of 
*bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>

*Sent:* Tuesday, June 19, 2018 3:38 PM
*To:* Stewart Bryant <mailto:stewart.bry...@gmail.com>>
*Cc:* SPRING WG List mailto:spring@ietf.org>>; Rob 
Shakir <mailto:robjs=40google....@dmarc.ietf.org>>

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

Hi Stewart,

Speaking as individual contributor, please see inline [Bruno]

*From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Stewart 
Bryant

*Sent:* Tuesday, June 19, 2018 1:19 PM

On 01/06/2018 17:05, Rob Shakir wrote:

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.


I am not sure where the line gets drawn with the per-path state 
statement. If I introduce a
binding-SID to allow the creation of a path, have I introduced 
per-path state or not? In practise
a management entity will choose between the infinity of possible 
binding-SIDs by considering
the need to create specific paths and I would imagine that many will 
be instantiated just-in-time.


I think that the key point is that the ingress creates the path by 
using SIDs to create

a concatenation of paths, policies and resources.

[Bruno] Agreed. And it can be argued that this creates a state on the 
ingress. An “outgoing” state, very roughly comparable to Next Hop 
Label Forwarding Entry (NHLFE))


However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state.

[Bruno] Adding a Binding SID to this SR policy introduces an 
“incoming” state, very roughly comparable to Incoming Label Map (ILM). 
But this gets additional benefit as it allows others SR nodes to use 
this state/SR policy.


I’m not sure that in such high level text, we need to make such 
distinction.


I think we might
be best served by deleting the text I have highlighted.

[Bruno] This text is mostly a copy/past from existing charter so is 
not really new:

“allow a node to steer a packet along an explicit

  route using information attached to the packet and

  without the need for per-path state information to be

  held at transit nodes. ”

At high level, I believe that this is a key distinct

Re: [spring] Updating the SPRING WG Charter

[David Allan I]

Hi

I do not quite get the same warm and fuzzy from the definition when thinking 
about multicast…..

The mapping of the binding SID to local policy is still IMO per path state. For 
a simple p2p path it is pretty straightforward as the mapping can be to a 
common policy abstraction at every node (send to ‘x’) .

In the case of multicast, the mapping would be unique at every node that had 
state for the binding SID (send copy to ‘a’ and ‘b’, send copy to ‘m’ and ‘q’ 
etc.) .  So some means of disseminating the mappings is required, and 
correlating them with the SID.  So the difference between a binding SID and a 
global SID for multicast IMO is choice of terminology.

So you have to decide if the whole “avoiding per path state” discussion is 
simply a desirable goal, or a strict admonition.  A bulk overprovisioning model 
to eliminate per path state will not work for multicast.

Cheers
Dave

From: spring  On Behalf Of Alexander Vainshtein
Sent: Tuesday, June 19, 2018 6:38 AM
To: bruno.decra...@orange.com; Stewart Bryant 
Cc: SPRING WG List ; Rob Shakir 

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

Bruno, Stewart and all,
I have looked up Section 5 “Binding Segment” of the Segment Routing 
Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
draft, and it says:

   In order to provide greater scalability, network opacity, and service
   independence, SR utilizes a Binding SID (BSID).  The BSID is bound to
   an SR policy, instantiation of which may involve a list of SIDs.  Any
   packets received with active segment = BSID are steered onto the
   bound SR Policy.

   A BSID may either be a local or a global SID.  If local, a BSID
   SHOULD be allocated from the SRLB.  If global, a BSID MUST be
   allocated from the SRGB.

   Use of a BSID allows the instantiation of the policy (the SID list)
   to be stored only on the node(s) which need to impose the policy.
   Direction of traffic to a node supporting the policy then only
   requires imposition of the BSID.  If the policy changes, this also
   means that only the nodes imposing the policy need to be updated.
   Users of the policy are not impacted.

From my POV this definition is fully aligned both with the Bruno’s last email 
and with my earlier argument why a BSID does not add a per-path state in the 
transit nodes.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Tuesday, June 19, 2018 3:38 PM
To: Stewart Bryant mailto:stewart.bry...@gmail.com>>
Cc: SPRING WG List mailto:spring@ietf.org>>; Rob Shakir 
mailto:robjs=40google....@dmarc.ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Stewart,

Speaking as individual contributor, please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, June 19, 2018 1:19 PM





On 01/06/2018 17:05, Rob Shakir wrote:
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.

I am not sure where the line gets drawn with the per-path state statement. If I 
introduce a
binding-SID to allow the creation of a path, have I introduced per-path state 
or not? In practise
a management entity will choose between the infinity of possible binding-SIDs 
by considering
the need to create specific paths and I would imagine that many will be 
instantiated just-in-time.

I think that the key point is that the ingress creates the path by using SIDs 
to create
a concatenation of paths, policies and resources.
[Bruno] Agreed. And it can be argued that this creates a state on the ingress. 
An “outgoing” state, very roughly comparable to Next Hop Label Forwarding Entry 
(NHLFE))
However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state.
[Bruno] Adding a Binding SID to this SR policy introduces an “incoming” state, 
very roughly comparable to Incoming Label Map (ILM). But this gets additional 
benefit as it allows others SR nodes to use this state/SR policy.
I’m not sure that in such high level text, we need to make such distinction.
I think we might
be best served by deleting the text I have highlighted.


[Bruno] This text is mostly a copy/past from existing charter so is not really 
new:

 “allow a node to steer a packet along an explicit
  route using information attached to the packet and
  without the need for per-path state information to be
  held at transit nodes. ”

At high level, I believe that this is a key distinction of spring/segment 
routing hence worth keeping in the high level introduction of the WG.
Now do we need to add text about more

Re: [spring] Updating the SPRING WG Charter

[Stewart Bryant]

On 19/06/2018 13:38, bruno.decra...@orange.com wrote:


Hi Stewart,

Speaking as individual contributor, please see inline [Bruno]

*From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Stewart 
Bryant

*Sent:* Tuesday, June 19, 2018 1:19 PM

On 01/06/2018 17:05, Rob Shakir wrote:

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.


I am not sure where the line gets drawn with the per-path state 
statement. If I introduce a
binding-SID to allow the creation of a path, have I introduced 
per-path state or not? In practise
a management entity will choose between the infinity of possible 
binding-SIDs by considering
the need to create specific paths and I would imagine that many will 
be instantiated just-in-time.


I think that the key point is that the ingress creates the path by 
using SIDs to create

a concatenation of paths, policies and resources.

[Bruno] Agreed. And it can be argued that this creates a state on the 
ingress. An “outgoing” state, very roughly comparable to Next Hop 
Label Forwarding Entry (NHLFE))


However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state.

[Bruno] Adding a Binding SID to this SR policy introduces an 
“incoming” state, very roughly comparable to Incoming Label Map (ILM). 
But this gets additional benefit as it allows others SR nodes to use 
this state/SR policy.


I’m not sure that in such high level text, we need to make such 
distinction.


I think we might
be best served by deleting the text I have highlighted.

[Bruno] This text is mostly a copy/past from existing charter so is 
not really new:

“allow a node to steer a packet along an explicit

  route using information attached to the packet and

  without the need for per-path state information to be

  held at transit nodes. ”



The text of course is a direct derivative of the original charter text:

The SPRING working group will define procedures that will allow
a node to steer a packet between any source and destination through
a SPRING region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.


However that pre-dates the introduction of binding SIDs which although 
can be considered a type of shared link are non-the-less state usually 
introduced to overcome a specific limitation in the SR hardware, since 
they achieve nothing that base SR cannot achieve without them.



At high level, I believe that this is a key distinction of 
spring/segment routing hence worth keeping in the high level 
introduction of the WG.


Now do we need to add text about more specific details, such as BSID? 
I’d rather not, as I don’t see what this would bring. I also don’t 
think that this sentence prohibits the creation of states when 
required/useful.



I suppose if you replaced:

and without the need for per-path state information to be held at 
transit nodes.


with

with minimum path state introduced at the transit nodes.

that would be closer to the design we have.

- Stewart



--Bruno


- Stewart




_

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] Updating the SPRING WG Charter

[Robert Raszuk]

Hi Stewart,

Nope that would be incorrect assumption.

Replication anchors would be where topologically it makes sense. And there
may not be at all any multicast trees those subject flows would need to
traverse. It is just about efficiency in content distribution.

Regards,
R.

On Tue, Jun 19, 2018 at 3:36 PM, Stewart Bryant 
wrote:

> For clarification:
>
> Can I assume that we are talking about replication at ingress to a series
> of  unicast SR paths each to an installed multicast tree close to egress?
>
> - Stewart
>
> On 10/06/2018 10:58, Robert Raszuk wrote:
>
> Hey Sasha,
>
> 100% agree with your last post. Very glad to see your support for
> spray/fan-out or if you will
> static MDTs to be in scope of SPRING.
>
> Based on number of WG members input expressed both at the meeting and on
> the list  I hope
> proposed SPRING charter will be updated soon to reflect that.
>
> Cheers,
> R.
>
> ​PS. Btw - I am also ok that ingress replication is not relevant to SPRING
> as it essentially happens at the
> ingress to the domain. ​
>
>
>
> On Sun, Jun 10, 2018 at 7:39 AM, Alexander Vainshtein <
> alexander.vainsht...@ecitele.com> wrote:
>
>> Robert,
>>
>> First of all, I did not say that your quote was inaccurate. I apologize
>> for possible misperception.
>>
>>
>>
>> Second, I believe that spray or fan-out (meaning support of externally
>> computed static MDTs) in SR-MPLS is a relevant focus area for the future WG
>> work. Of course the solution must be aligned with the SPRING and MPLS
>> architecture, and this imposes additional restrictions on how such a
>> solution would look.
>>
>>
>>
>> Last but not least, I have differentiated (from my first email on this
>> thread) *ingress replication* *in SR* from the more generic *multicast
>> support *in SR:
>>
>> -  The latter is quite acceptable to me
>>
>> -  The former, IMHO, should be left out of scope.
>>
>>
>>
>> Hope this helps to clarify my position.
>>
>> Regards, and, again, apologies for possible misinterpretation.
>>
>>
>>
>> Sasha
>>
>
>
> ___
> spring mailing listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring
>
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Stewart Bryant]

For clarification:

Can I assume that we are talking about replication at ingress to a 
series of  unicast SR paths each to an installed multicast tree close to 
egress?


- Stewart


On 10/06/2018 10:58, Robert Raszuk wrote:

Hey Sasha,

100% agree with your last post. Very glad to see your support for 
spray/fan-out or if you will

static MDTs to be in scope of SPRING.

Based on number of WG members input expressed both at the meeting and 
on the list  I hope

proposed SPRING charter will be updated soon to reflect that.

Cheers,
R.

​PS. Btw - I am also ok that ingress replication is not relevant to 
SPRING as it essentially happens at the

ingress to the domain. ​



On Sun, Jun 10, 2018 at 7:39 AM, Alexander Vainshtein 
> wrote:


Robert,

First of all, I did not say that your quote was inaccurate. I
apologize for possible misperception.

Second, I believe that spray or fan-out (meaning support of
externally computed static MDTs) in SR-MPLS is a relevant focus
area for the future WG work. Of course the solution must be
aligned with the SPRING and MPLS architecture, and this imposes
additional restrictions on how such a solution would look.

Last but not least, I have differentiated (from my first email on
this thread) */ingress replication/* *in SR* from the more generic
*multicast support *in SR:

-The latter is quite acceptable to me

-The former, IMHO, should be left out of scope.

Hope this helps to clarify my position.

Regards, and, again, apologies for possible misinterpretation.

Sasha



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


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

Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein]

Bruno, Stewart and all,
I have looked up Section 5 “Binding Segment” of the Segment Routing 
Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
draft, and it says:

   In order to provide greater scalability, network opacity, and service
   independence, SR utilizes a Binding SID (BSID).  The BSID is bound to
   an SR policy, instantiation of which may involve a list of SIDs.  Any
   packets received with active segment = BSID are steered onto the
   bound SR Policy.

   A BSID may either be a local or a global SID.  If local, a BSID
   SHOULD be allocated from the SRLB.  If global, a BSID MUST be
   allocated from the SRGB.

   Use of a BSID allows the instantiation of the policy (the SID list)
   to be stored only on the node(s) which need to impose the policy.
   Direction of traffic to a node supporting the policy then only
   requires imposition of the BSID.  If the policy changes, this also
   means that only the nodes imposing the policy need to be updated.
   Users of the policy are not impacted.

From my POV this definition is fully aligned both with the Bruno’s last email 
and with my earlier argument why a BSID does not add a per-path state in the 
transit nodes.


Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Tuesday, June 19, 2018 3:38 PM
To: Stewart Bryant 
Cc: SPRING WG List ; Rob Shakir 

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

Hi Stewart,

Speaking as individual contributor, please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, June 19, 2018 1:19 PM






On 01/06/2018 17:05, Rob Shakir wrote:
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.

I am not sure where the line gets drawn with the per-path state statement. If I 
introduce a
binding-SID to allow the creation of a path, have I introduced per-path state 
or not? In practise
a management entity will choose between the infinity of possible binding-SIDs 
by considering
the need to create specific paths and I would imagine that many will be 
instantiated just-in-time.

I think that the key point is that the ingress creates the path by using SIDs 
to create
a concatenation of paths, policies and resources.
[Bruno] Agreed. And it can be argued that this creates a state on the ingress. 
An “outgoing” state, very roughly comparable to Next Hop Label Forwarding Entry 
(NHLFE))
However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state.
[Bruno] Adding a Binding SID to this SR policy introduces an “incoming” state, 
very roughly comparable to Incoming Label Map (ILM). But this gets additional 
benefit as it allows others SR nodes to use this state/SR policy.
I’m not sure that in such high level text, we need to make such distinction.
I think we might
be best served by deleting the text I have highlighted.



[Bruno] This text is mostly a copy/past from existing charter so is not really 
new:

 “allow a node to steer a packet along an explicit
  route using information attached to the packet and
  without the need for per-path state information to be
  held at transit nodes. ”

At high level, I believe that this is a key distinction of spring/segment 
routing hence worth keeping in the high level introduction of the WG.
Now do we need to add text about more specific details, such as BSID? I’d 
rather not, as I don’t see what this would bring. I also don’t think that this 
sentence prohibits the creation of states when required/useful.
--Bruno

- Stewart






_



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.

___

This e-mail message is in

Re: [spring] Updating the SPRING WG Charter

[bruno.decraene]

Hi Stewart,

Speaking as individual contributor, please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, June 19, 2018 1:19 PM





On 01/06/2018 17:05, Rob Shakir wrote:
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.

I am not sure where the line gets drawn with the per-path state statement. If I 
introduce a
binding-SID to allow the creation of a path, have I introduced per-path state 
or not? In practise
a management entity will choose between the infinity of possible binding-SIDs 
by considering
the need to create specific paths and I would imagine that many will be 
instantiated just-in-time.

I think that the key point is that the ingress creates the path by using SIDs 
to create
a concatenation of paths, policies and resources.
[Bruno] Agreed. And it can be argued that this creates a state on the ingress. 
An “outgoing” state, very roughly comparable to Next Hop Label Forwarding Entry 
(NHLFE))
However it could be argued that
as soon as we introduced Binding SIDs we introduced per-path state.
[Bruno] Adding a Binding SID to this SR policy introduces an “incoming” state, 
very roughly comparable to Incoming Label Map (ILM). But this gets additional 
benefit as it allows others SR nodes to use this state/SR policy.
I’m not sure that in such high level text, we need to make such distinction.
I think we might
be best served by deleting the text I have highlighted.


[Bruno] This text is mostly a copy/past from existing charter so is not really 
new:

 “allow a node to steer a packet along an explicit
  route using information attached to the packet and
  without the need for per-path state information to be
  held at transit nodes. ”

At high level, I believe that this is a key distinction of spring/segment 
routing hence worth keeping in the high level introduction of the WG.
Now do we need to add text about more specific details, such as BSID? I’d 
rather not, as I don’t see what this would bring. I also don’t think that this 
sentence prohibits the creation of states when required/useful.
--Bruno

- Stewart





_

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] Updating the SPRING WG Charter

[Ruediger.Geib]

There’s no objection against policies installed at ingress interfaces to an SR 
domain. Rob correctly states, that the SR architecture does not require per 
path state at transit nodes. And that’s good and correct. I’d like to see the 
number of signaling protocols in the SR core network being reduced as compared 
with today’s MPLS network, not increased.

There’s RSVP-TE for MPLS, which can be deployed for services requiring per path 
state at transit nodes.

Regards,

Ruediger

Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Stewart Bryant
Gesendet: Dienstag, 19. Juni 2018 13:19
An: Rob Shakir ; SPRING WG List 

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




On 01/06/2018 17:05, Rob Shakir wrote:
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.

I am not sure where the line gets drawn with the per-path state statement. If I 
introduce a
binding-SID to allow the creation of a path, have I introduced per-path state 
or not? In practise
a management entity will choose between the infinity of possible binding-SIDs 
by considering
the need to create specific paths and I would imagine that many will be 
instantiated just-in-time.

I think that the key point is that the ingress creates the path by using SIDs 
to create
a concatenation of paths, policies and resources. However it could be argued 
that
as soon as we introduced Binding SIDs we introduced per-path state. I think we 
might
be best served by deleting the text I have highlighted.

- Stewart




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

Re: [spring] Updating the SPRING WG Charter

[Stewart Bryant]

On 01/06/2018 17:05, Rob Shakir wrote:
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.


I am not sure where the line gets drawn with the per-path state 
statement. If I introduce a
binding-SID to allow the creation of a path, have I introduced per-path 
state or not? In practise
a management entity will choose between the infinity of possible 
binding-SIDs by considering
the need to create specific paths and I would imagine that many will be 
instantiated just-in-time.


I think that the key point is that the ingress creates the path by using 
SIDs to create
a concatenation of paths, policies and resources. However it could be 
argued that
as soon as we introduced Binding SIDs we introduced per-path state. I 
think we might

be best served by deleting the text I have highlighted.

- Stewart





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

Re: [spring] Updating the SPRING WG Charter

[bruno.decraene]

Hi Daniel,

Could you clarify what you mean by “Multicast in SR”?
I could think of four different things:
a) locally allocating a SID to some existing replication structures, such as 
tree installed in the FIB (PIM, mLDP, P2MP RSVP-TE…), tree defined in the 
packet (BIER), ingress replication on interfaces/tunnels. The latter been 
called “Spray” in some documents.
b) a new way to signal and install tree in FIB across the networks
c) a new way to install tree in FIB across the networks without explicit 
signaling of the trees
d) a new way to encode tree in the packet without creating states in the 
network.
e) others?

On my side, “a” seems a reasonable, short and constraint extension(s), “d” 
seems like a duplication of BIER.

Regards,
--Bruno


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Voyer, Daniel
Sent: Wednesday, June 06, 2018 10:20 PM
To: Zafar Ali (zali); Rob Shakir; Michael McBride
Cc: Xiejingrong; spring@ietf.org
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,

I support and agree w/ Zafar.

Multicast in SR is much needed and there is lots of development that needs to 
happen, whether for SRv6 or with SR-MPLS. The core architecture and development 
need to be included in this working group.

Thanks,
dan


From: "Zafar Ali (zali)" 
Date: Wednesday, June 6, 2018 at 3:14 PM
To: Rob Shakir , Michael McBride 

Cc: Xiejingrong , "spring@ietf.org" , 
"Zafar Ali (zali)" 
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

The multicast in SR belongs to the same category as I highlighted in my last 
email. Just to repeat …

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

Specifically, multicast in SR is included in that list with the "Ingress 
replication SID (Tree SID /spray)" bullet (and support during the WG meeting) 
but is missing in the proposed charter text. So, I agree with Xiejingrong and 
Michael highlighting the same. There is already interest and agreement shown by 
the WG to include multicast in SR in the charter.

In the light of the above, please add a milestone for the WG to specify 
architecture, and the required protocol extensions for multicast in SR with 
MPLS and IPv6 data planes, including specification of the ingress replication 
SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly agree that the 
actual protocol extension work should be done at the WG that owns the protocol.

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride 
Cc: Xiejingrong , "spring@ietf.org" 
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.
On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
mailto:michael.mcbr...@huawei.com>> wrote:
It would be helpful, while updating the charter, to state whether multicast in 
SR is in/out of scope in order to know which wg to take our future work.

I think this is impractical. If we state everything that is in or out of scope, 
we'll end up with a laundry list. The aim of the charter is to define clearly 
the work that the WG should focus on. It does not mean that we can never host 
discussion of individual drafts if they are relevant. If there are 
requirements, we can always recharter if something new becomes the highest 
priority for the industry w.r.t SR.

Kind regards,
r.

_

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] Updating the SPRING WG Charter

[Loa Andersson]

Rob,

Two things

- do we have an available current state of the charter-to-bu-updated
  text.
- inline plz

On 2018-06-04 18:44, Rob Shakir wrote:

Michael,

Thanks for the comment.

On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
mailto:michael.mcbr...@huawei.com>> wrote:


It would be helpful, while updating the charter, to state whether
multicast in SR is in/out of scope in order to know which wg to take
our future work.


I think this is impractical. 


Yes, I agree that it is impractical have "everything" out of scope
listed. However for things being brought up for discussion we need
clear decisions/consensus documented on the mailing list.

Does your statement mean that "multicast in SR" is out of scope for
SPRING?

/Loa


If we state everything that is in or out of
scope, we'll end up with a laundry list. The aim of the charter is to 
define clearly the work that the WG should focus on. It does not mean 
that we can never host discussion of individual drafts if they are 
relevant. If there are requirements, we can always recharter if 
something new becomes the highest priority for the industry w.r.t SR.


Kind regards,
r.


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



--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

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

Re: [spring] Updating the SPRING WG Charter

[Zafar Ali (zali)]

Hi Jie,

While I look forward to reviewing the draft, at the moment of writing the 
charter no such details were available. At the moment we do not know if this 
would be an architecturally correct option to adopt in segment routing; what 
type of complexity, statefulness and scalability concerns it brings to the 
table. We also don't know if this is a matter of local implementation or are we 
better off if it is entirely done at the controller, etc.

The work you are doing is already in the charter by the virtue of "SPRING WG 
serves as a forum to discuss SPRING networks operations, define new 
applications, and specify extensions of Segment Routing technologies."

What puzzles me is the logic of adding this task to the "work items" list. And 
if we go with the same logic, why did we drop a few items raised by many 
(before/ during IETF in London and as part of the review of the charter draft) 
on the list for inclusion in the "work items" list. I am hoping for consistency 
in making such determination in the final version of the charter.

Thanks

Regards … Zafar

From: spring  on behalf of "Dongjie (Jimmy)" 

Date: Wednesday, June 13, 2018 at 11:26 PM
To: "Zafar Ali (zali)" , 
"bruno.decra...@orange.com" 
Cc: SPRING WG List , "Zafar Ali (zali)" , Rob 
Shakir 
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Zafar,

As mentioned in my previous mail, the VPN+ drafts and this work item require 
new functionality to be added to SR, which is to associate SR with particular 
allocated resources and treatment. IMO this is not covered by existing SR 
mechanisms. It is different from Diffserv QoS, and it is not pure 
controller-based accounting, because in the data plane some mechanism is needed 
to make sure different services will be treated accordingly and not impact each 
other.

Thanks for the comments in London, we are working on the updates of the VPN+ 
drafts, hopefully they will be published for open review soon.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, June 13, 2018 11:30 PM
To: bruno.decra...@orange.com; Zafar Ali (zali) 

Cc: SPRING WG List ; Zafar Ali (zali) ; Rob 
Shakir 
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Bruno,

I am aware of the VPN+ draft but IMO this document or Slicing, in general, is 
an informational use-case document (E.g., similarly SD-WAN does not have a 
milestone in the Charter). I do not think that there is any new behavior needed 
beyond SRTE, SRVPN, Flex-Algo, Diffserv QoS and SR SFC, etc. What is missing is 
the controller doing the bandwidth (resource) accounting but this outside the 
scope of IETF. Furthermore, the specifics in the VPN+ specifics draft against 
this milestone are missing. The same comments were also raised when 
draft-dong-spring-sr-for-enhanced-vpn was presented to the Spring WG in London.

Thanks

Regards … Zafar

From: "bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>" 
mailto:bruno.decra...@orange.com>>
Date: Tuesday, June 12, 2018 at 12:13 PM
To: "Zafar Ali (zali)" 
mailto:zali=40cisco@dmarc.ietf.org>>
Cc: "Zafar Ali (zali)" mailto:z...@cisco.com>>, Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>, 
SPRING WG List mailto:spring@ietf.org>>
Subject: RE: [spring] Updating the SPRING WG Charter

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:


  *   Using SR as the mechanism to identify sets of resources in networks with 
SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft 
associated with this milestone beyond what is already covered by other 
milestones (e.g., by “Segment Routing policies and the associated steering and 
traffic engineering mechanisms”). What specific deliverable you have in mind? 
Is there an individual(s) draft against this milestone? Please advise.

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Friday, June 1, 2018 at 12:07 PM
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 wo

Re: [spring] Updating the SPRING WG Charter

[Dongjie (Jimmy)]

Hi Zafar,

As mentioned in my previous mail, the VPN+ drafts and this work item require 
new functionality to be added to SR, which is to associate SR with particular 
allocated resources and treatment. IMO this is not covered by existing SR 
mechanisms. It is different from Diffserv QoS, and it is not pure 
controller-based accounting, because in the data plane some mechanism is needed 
to make sure different services will be treated accordingly and not impact each 
other.

Thanks for the comments in London, we are working on the updates of the VPN+ 
drafts, hopefully they will be published for open review soon.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, June 13, 2018 11:30 PM
To: bruno.decra...@orange.com; Zafar Ali (zali) 

Cc: SPRING WG List ; Zafar Ali (zali) ; Rob 
Shakir 
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Bruno,

I am aware of the VPN+ draft but IMO this document or Slicing, in general, is 
an informational use-case document (E.g., similarly SD-WAN does not have a 
milestone in the Charter). I do not think that there is any new behavior needed 
beyond SRTE, SRVPN, Flex-Algo, Diffserv QoS and SR SFC, etc. What is missing is 
the controller doing the bandwidth (resource) accounting but this outside the 
scope of IETF. Furthermore, the specifics in the VPN+ specifics draft against 
this milestone are missing. The same comments were also raised when 
draft-dong-spring-sr-for-enhanced-vpn was presented to the Spring WG in London.

Thanks

Regards … Zafar

From: "bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>" 
mailto:bruno.decra...@orange.com>>
Date: Tuesday, June 12, 2018 at 12:13 PM
To: "Zafar Ali (zali)" 
mailto:zali=40cisco@dmarc.ietf.org>>
Cc: "Zafar Ali (zali)" mailto:z...@cisco.com>>, Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>, 
SPRING WG List mailto:spring@ietf.org>>
Subject: RE: [spring] Updating the SPRING WG Charter

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:


  *   Using SR as the mechanism to identify sets of resources in networks with 
SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft 
associated with this milestone beyond what is already covered by other 
milestones (e.g., by “Segment Routing policies and the associated steering and 
traffic engineering mechanisms”). What specific deliverable you have in mind? 
Is there an individual(s) draft against this milestone? Please advise.

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Friday, June 1, 2018 at 12:07 PM
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). 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 s

Re: [spring] Updating the SPRING WG Charter

[Zafar Ali (zali)]

Hi Bruno,

I am aware of the VPN+ draft but IMO this document or Slicing, in general, is 
an informational use-case document (E.g., similarly SD-WAN does not have a 
milestone in the Charter). I do not think that there is any new behavior needed 
beyond SRTE, SRVPN, Flex-Algo, Diffserv QoS and SR SFC, etc. What is missing is 
the controller doing the bandwidth (resource) accounting but this outside the 
scope of IETF. Furthermore, the specifics in the VPN+ specifics draft against 
this milestone are missing. The same comments were also raised when 
draft-dong-spring-sr-for-enhanced-vpn was presented to the Spring WG in London.

Thanks

Regards … Zafar

From: "bruno.decra...@orange.com" 
Date: Tuesday, June 12, 2018 at 12:13 PM
To: "Zafar Ali (zali)" 
Cc: "Zafar Ali (zali)" , Rob Shakir 
, SPRING WG List 
Subject: RE: [spring] Updating the SPRING WG Charter

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:


  *   Using SR as the mechanism to identify sets of resources in networks with 
SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft 
associated with this milestone beyond what is already covered by other 
milestones (e.g., by “Segment Routing policies and the associated steering and 
traffic engineering mechanisms”). What specific deliverable you have in mind? 
Is there an individual(s) draft against this milestone? Please advise.

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

Date: Friday, June 1, 2018 at 12:07 PM
To: SPRING WG List 
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). 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 and traffic engineering
  mechanisms.

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

o SRv6 network programming for the underlay

Re: [spring] Updating the SPRING WG Charter

[Ruediger.Geib]

Dear Ji,

you’ve written „Although SR can rely on the network controller for global 
traffic optimization and placement, there is no mechanism to provide resource 
guarantee and service separation in the data plane.”

If this is linked to maintenance of per segment (or per segment range) state on 
other parts of the SR domain than the SR edge router, it is not within charter 
of the SR WG, I think.

Regards,

Ruediger



Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Dongjie (Jimmy)
Gesendet: Mittwoch, 13. Juni 2018 14:19
An: bruno.decra...@orange.com; Zafar Ali (zali) 

Cc: SPRING WG List ; Zafar Ali (zali) ; Rob 
Shakir 
Betreff: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

As Bruno and Sasha have pointed out, the enhanced VPN drafts are relevant to 
this work item.

As mentioned in one of my previous email (the pointer is also provided in 
Bruno’s mail), currently SR is mainly designed for source routing based path 
steering, comparing to RSVP-TE, it does not provide the functionality of 
allocating and identifying different set of resources on particular network 
segments. Although SR can rely on the network controller for global traffic 
optimization and placement, there is no mechanism to provide resource guarantee 
and service separation in the data plane. Some customers have expressed their 
concerns about SR’s lack of this kind of capability, thus we believe this work 
item should be included in the updated charter.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Wednesday, June 13, 2018 12:13 AM
To: Zafar Ali (zali) 
mailto:zali=40cisco@dmarc.ietf.org>>
Cc: SPRING WG List mailto:spring@ietf.org>>; Zafar Ali (zali) 
mailto:z...@cisco.com>>; Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:


  *   Using SR as the mechanism to identify sets of resources in networks with 
SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft 
associated with this milestone beyond what is already covered by other 
milestones (e.g., by “Segment Routing policies and the associated steering and 
traffic engineering mechanisms”). What specific deliverable you have in mind? 
Is there an individual(s) draft against this milestone? Please advise.

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Friday, June 1, 2018 at 12:07 PM
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). 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
technolo

Re: [spring] Updating the SPRING WG Charter

[Dongjie (Jimmy)]

Dear Zafar,

As Bruno and Sasha have pointed out, the enhanced VPN drafts are relevant to 
this work item.

As mentioned in one of my previous email (the pointer is also provided in 
Bruno’s mail), currently SR is mainly designed for source routing based path 
steering, comparing to RSVP-TE, it does not provide the functionality of 
allocating and identifying different set of resources on particular network 
segments. Although SR can rely on the network controller for global traffic 
optimization and placement, there is no mechanism to provide resource guarantee 
and service separation in the data plane. Some customers have expressed their 
concerns about SR’s lack of this kind of capability, thus we believe this work 
item should be included in the updated charter.

Best regards,
Jie

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of 
bruno.decra...@orange.com
Sent: Wednesday, June 13, 2018 12:13 AM
To: Zafar Ali (zali) 
Cc: SPRING WG List ; Zafar Ali (zali) ; Rob 
Shakir 
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Zafar,

Please see inline [Bruno]

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 3:45 PM
To: Rob Shakir; SPRING WG List
Cc: Zafar Ali (zali)
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:


  *   Using SR as the mechanism to identify sets of resources in networks with 
SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft 
associated with this milestone beyond what is already covered by other 
milestones (e.g., by “Segment Routing policies and the associated steering and 
traffic engineering mechanisms”). What specific deliverable you have in mind? 
Is there an individual(s) draft against this milestone? Please advise.

[Bruno] Would the following pointers provide enough context?
https://mailarchive.ietf.org/arch/msg/spring/canXoxLZCwRZ_yFcV3U7RXRwfpM
https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02#section-4.3.6
https://tools.ietf.org/html/draft-dong-spring-sr-for-enhanced-vpn-00#section-2

Regards,
--Bruno

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Friday, June 1, 2018 at 12:07 PM
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). 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

Re: [spring] Updating the SPRING WG Charter

[Jeff Tantsura]

Rob,

 

Sorry for the delay, please see inline.

Thanks!

 

Cheers,

Jeff

From: Rob Shakir 
Date: Sunday, June 3, 2018 at 14:36
To: Jeff Tantsura 
Cc: SPRING WG List 
Subject: Re: [spring] Updating the SPRING WG Charter

 

Hi Jeff,

 

Thanks for the comments.

 

On Fri, Jun 1, 2018 at 9:44 AM Jeff Tantsura  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”

 

robjs> I don't think that SPRING should limit itself to having to just work on 
dataplane technologies. The functional specifications or architectures that are 
proposed are likely to span both data, control, and management planes (e.g., 
YANG models, counter specifications). I'd be interested if you disagree?

[jeff] I absolutely agree with you that the work should have all abovementioned 
planes, it is more to how the sentence reads, I meant not to limit the works to 
dataplane only but a common convention, when we say SR-MPLS we really mean SR 
with MPLS data plane, same for SRv6

 

*snip*

 

o Using SR

[jeff] SR conveyed metadata perhaps? Think of BSID x-connect into another layer

 

robjs> I'd argue that this is more than metadata, it's really a forwarding 
instruction that says to send to some other layer, or that is interpreted in 
another domain. Metadata to me would mean information that we're carrying on 
the packet that *isn't* used for forwarding.

[jeff] we’d disagree on this one, I would not consider setting the context (ie 
where to lookup) as a forwarding instruction  

 

*snip*

 * lsr on OSPF and IS-IS extensions to flood SPRING-related information

[jeff] in RIFT we plan to support SR as well

 

robjs> This is probably RIFT co-ordinating with SPRING. I'd rather avoid 
listing another protocol here without there being SPRING work that affects it. 
Of course, please do involve SPRING in discussions of SR support in RIFT.

[jeff] Ack

 

*snip*

 * teas on generic traffic engineering architecture

[jeff] rtgwg for fast convergence related topics

 

robjs> Thanks -- yes, given all the work in rtgwg on this topic, this should 
definitely be added.

[jeff] thanks!

 

Thanks,

r.

 

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

Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein]

Zafar,
From my POV one possible answer to your question could be found in Section 
4.3.6 and 4.4 of the Enhanced 
VPN<https://tools.ietf.org/html/draft-bryant-rtgwg-enhanced-vpn-02> draft.
This draft mentions new SR instructions that could, say, define not just 
forwarding behavior of packets but also their QoS treatment.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Tuesday, June 12, 2018 4:45 PM
To: Rob Shakir ; SPRING WG List 

Cc: Zafar Ali (zali) 
Subject: Re: [spring] Updating the SPRING WG Charter

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:

.  Using SR as the mechanism to identify sets of resources in networks 
with SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft 
associated with this milestone beyond what is already covered by other 
milestones (e.g., by “Segment Routing policies and the associated steering and 
traffic engineering mechanisms”). What specific deliverable you have in mind? 
Is there an individual(s) draft against this milestone? Please advise.

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Friday, June 1, 2018 at 12:07 PM
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). 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 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 The inter-working between SRv6 and SR-MPLS.

o Using SR as the mechanism to identify sets of resources in networks with
  SR-MPLS and SRv6 dataplanes.

Any of the above may require architectural ext

Re: [spring] Updating the SPRING WG Charter

[Zafar Ali (zali)]

Dear Rob, Bruno,

I have a question on the specifics of the following milestone:


  *   Using SR as the mechanism to identify sets of resources in networks with 
SR-MPLS and SRv6 dataplanes.

I do not know of any specific use-case, requirement or an individual draft 
associated with this milestone beyond what is already covered by other 
milestones (e.g., by “Segment Routing policies and the associated steering and 
traffic engineering mechanisms”). What specific deliverable you have in mind? 
Is there an individual(s) draft against this milestone? Please advise.

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

Date: Friday, June 1, 2018 at 12:07 PM
To: SPRING WG List 
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). 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 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 The inter-working between SRv6 and SR-MPLS.

o Using SR 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 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 paths
* teas on generic traffic engineering architecture

Please comment on the contents of the charter text on 

Re: [spring] Updating the SPRING WG Charter

[Bernier, Daniel]

Hi Rob,



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



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



Cheers,



Daniel Bernier


From: spring  on behalf of Zafar Ali (zali) 

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

Hi Rob,

Re: Linda comment on SR assisted SD-WAN.

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

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


  *   Interactions between overlay/applications and optimized underlay

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

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

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

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

Hi Linda,

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

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

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

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

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

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

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

 *snip*

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

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

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

Thanks for the comments.

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

Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk]

Hey Sasha,

100% agree with your last post. Very glad to see your support for
spray/fan-out or if you will
static MDTs to be in scope of SPRING.

Based on number of WG members input expressed both at the meeting and on
the list  I hope
proposed SPRING charter will be updated soon to reflect that.

Cheers,
R.

​PS. Btw - I am also ok that ingress replication is not relevant to SPRING
as it essentially happens at the
ingress to the domain. ​



On Sun, Jun 10, 2018 at 7:39 AM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Robert,
>
> First of all, I did not say that your quote was inaccurate. I apologize
> for possible misperception.
>
>
>
> Second, I believe that spray or fan-out (meaning support of externally
> computed static MDTs) in SR-MPLS is a relevant focus area for the future WG
> work. Of course the solution must be aligned with the SPRING and MPLS
> architecture, and this imposes additional restrictions on how such a
> solution would look.
>
>
>
> Last but not least, I have differentiated (from my first email on this
> thread) *ingress replication* *in SR* from the more generic *multicast
> support *in SR:
>
> -  The latter is quite acceptable to me
>
> -  The former, IMHO, should be left out of scope.
>
>
>
> Hope this helps to clarify my position.
>
> Regards, and, again, apologies for possible misinterpretation.
>
>
>
> Sasha
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein]

Robert,
First of all, I did not say that your quote was inaccurate. I apologize for 
possible misperception.

Second, I believe that spray or fan-out (meaning support of externally computed 
static MDTs) in SR-MPLS is a relevant focus area for the future WG work. Of 
course the solution must be aligned with the SPRING and MPLS architecture, and 
this imposes additional restrictions on how such a solution would look.

Last but not least, I have differentiated (from my first email on this thread) 
ingress replication in SR from the more generic multicast support in SR:

-  The latter is quite acceptable to me

-  The former, IMHO, should be left out of scope.

Hope this helps to clarify my position.
Regards, and, again, apologies for possible misinterpretation.

Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Saturday, June 9, 2018 10:50 PM
To: Alexander Vainshtein 
Cc: spring@ietf.org; Xiejingrong ; Michael McBride 
; Rob Shakir ; 
Paul Mattes ; Zafar Ali (zali) ; Eric C 
Rosen ; Voyer, Daniel 
Subject: Re: [spring] Updating the SPRING WG Charter


Sasha,

1. Where did I say it is a requirement ? My quote was precise and it clearly 
said that this is recommended.

2. Nothing in this thread requires use of domain-wide labels. All required 
functionality will work just fine with domain-wide indexes - so even we I or 
anyone one else said here anything about "domain-wide labels" fell free to 
substitute it with "domain-wide index" if this will make you happy.

3. To constructively move fwd let me propose we drop SR-MPLS all together from 
support of spray or fan-out functionality in the charter and just make sure 
charter reflect such support for SRv6 only. Now let's sit and watch how the 
proponents of index based offset instead of global SRGB will react if MPLS 
based network will miss such useful functionality :)

Cheers,
R.



On Sat, Jun 9, 2018 at 8:53 PM, Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Robert,
I think that you have cut the quoted text from the Segment Routing 
Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
draft a bit too short. The complete fragment says:

   Where possible, it is recommended that identical SRGBs be configured
   on all nodes in an SR Domain.  This simplifies troubleshooting as the
   same label will be associated with the same prefix on all nodes.  In
   addition, it simplifies support for anycast as detailed in
   Section 
3.3<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.3>.

In other words,  the Segment Routing Architecture draft:

-  Does not consider identical SRGBs on all nodes in an SR domain as a 
requirement.

-  Explains that such configuration, if used, simplifies 
troubleshooting and support of anycast segments. With regard to the latter, 
please note that the Anycast 
Segments<https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02>
 draft defines a mechanism that facilitates usage of anycast segments in an 
environment with different SRGBs on different nodes.

Therefore, from my POV, domain-wide labels have been purged (for quite some 
time now) from the SR-MPLS architecture. I do not think that they should be 
re-introduced.

My 2c,
Sasha

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk]

Sasha,

1. Where did I say it is a requirement ? My quote was precise and it
clearly said that this is recommended.

2. Nothing in this thread requires use of domain-wide labels. All required
functionality will work just fine with domain-wide indexes - so even we I
or anyone one else said here anything about "domain-wide labels" fell free
to substitute it with "domain-wide index" if this will make you happy.

3. To constructively move fwd let me propose we drop SR-MPLS all together
from support of spray or fan-out functionality in the charter and just make
sure charter reflect such support for SRv6 only. Now let's sit and watch
how the proponents of index based offset instead of global SRGB will react
if MPLS based network will miss such useful functionality :)

Cheers,
R.



On Sat, Jun 9, 2018 at 8:53 PM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Robert,
>
> I think that you have cut the quoted text from the Segment Routing
> Architecture
>  draft
> a bit too short. The complete fragment says:
>
>
>
>Where possible, it is recommended that identical SRGBs be configured
>
>on all nodes in an SR Domain.  This simplifies troubleshooting as the
>
>same label will be associated with the same prefix on all nodes.  In
>
>addition, it simplifies support for anycast as detailed in
>
>Section 3.3
> 
> .
>
>
>
> In other words,  the Segment Routing Architecture draft:
>
> -  Does not consider identical SRGBs on all nodes in an SR domain
> as a requirement.
>
> -  Explains that such configuration, if used, simplifies
> troubleshooting and support of anycast segments. With regard to the latter,
> please note that the Anycast Segments
> 
> draft defines a mechanism that facilitates usage of anycast segments in an
> environment with different SRGBs on different nodes.
>
>
>
> Therefore, from my POV, domain-wide labels have been purged (for quite
> some time now) from the SR-MPLS architecture. I do not think that they
> should be re-introduced.
>
>
>
> My 2c,
>
> Sasha
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein]

Robert,
I think that you have cut the quoted text from the Segment Routing 
Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
draft a bit too short. The complete fragment says:

   Where possible, it is recommended that identical SRGBs be configured
   on all nodes in an SR Domain.  This simplifies troubleshooting as the
   same label will be associated with the same prefix on all nodes.  In
   addition, it simplifies support for anycast as detailed in
   Section 
3.3<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.3>.

In other words,  the Segment Routing Architecture draft:

-  Does not consider identical SRGBs on all nodes in an SR domain as a 
requirement.

-  Explains that such configuration, if used, simplifies 
troubleshooting and support of anycast segments. With regard to the latter, 
please note that the Anycast 
Segments<https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02>
 draft defines a mechanism that facilitates usage of anycast segments in an 
environment with different SRGBs on different nodes.


Therefore, from my POV, domain-wide labels have been purged (for quite some 
time now) from the SR-MPLS architecture. I do not think that they should be 
re-introduced.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, June 8, 2018 11:44 PM
To: Alexander Vainshtein 
Cc: Paul Mattes ; spring@ietf.org; Xiejingrong 
; Michael McBride ; Rob 
Shakir ; Zafar Ali (zali) ; 
Eric C Rosen ; Voyer, Daniel 
Subject: Re: [spring] Updating the SPRING WG Charter

Folks,

The only reason why SR-MPLS architecture is using indexes as opposed to domain 
wide labels is a claim from few folks that possibly in some networks deployed 
platforms would not be able to use the same global label block for SR.

So SR-MPLS architecture agreed to use index to offset possible per platform 
label block.

That said number of real deployment do use global (domain wide) identical block 
on all nodes and that is the actual recommendation from section 3.1.2 of SR 
architecture

"Where possible, it is recommended that identical SRGBs be configured on all 
nodes in an SR Domain."

But none of this really matters for the discussion at hand. Embedding 
instruction for specific function can be easily done within programmed domain 
wide index offset.

Best,
R.


On Fri, Jun 8, 2018 at 10:21 PM, Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Robert, Paul and all,
I concur with Paul.
Domain-wide labels have been successfully purged from SR-MPLS for quite some 
time now, and, from my POV this purge is irreversible now.
My 2c.
Thumb typed by Sasha Vainshtein



___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk]

Folks,

The only reason why SR-MPLS architecture is using indexes as opposed to
domain wide labels is a claim from few folks that possibly in some networks
deployed platforms would not be able to use the same global label block for
SR.

So SR-MPLS architecture agreed to use index to offset possible per platform
label block.

That said number of real deployment do use global (domain wide) identical
block on all nodes and that is the actual recommendation from section 3.1.2
of SR architecture

"Where possible, it is recommended that identical SRGBs be configured on
all nodes in an SR Domain."

But none of this really matters for the discussion at hand. Embedding
instruction for specific function can be easily done within programmed
domain wide index offset.

Best,
R.


On Fri, Jun 8, 2018 at 10:21 PM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Robert, Paul and all,
> I concur with Paul.
> Domain-wide labels have been successfully purged from SR-MPLS for quite
> some time now, and, from my POV this purge is irreversible now.
>
> My 2c.
>
> Thumb typed by Sasha Vainshtein
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Voyer, Daniel]

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

Specifically, multicast in SR is included in that list with the "Ingress 
replication SID (Tree SID /spray)" bullet (and support during the WG meeting) 
but is missing in the proposed charter text. So, I agree with Xiejingrong and 
Michael highlighting the same. There is already interest and agreement shown by 
the WG to include multicast in SR in the charter.

This list was a recap of what had been discussed on the mailing list. It was 
not the proposed exhaustive list.
[DV] I thought this was a list proposed by the working group as a response to 
AD’s request ? Didn’t we debate this list in our last wg meeting ?!

The preference in the charter text (after much discussion) is to ensure that 
SPRING has a set of focus areas to work on. This does not preclude interested 
individuals doing other work - and even bringing it to SPRING. We can change 
the charter in the future if new work comes up that isn't within the charter.

I would point out that the narrow scope that we (the SPRING WG) initially had 
to deliver on has taken almost five years since we initially discussed it (see 
this thread 
regarding chartering STATUS as it was at the time). In this period of time, 
real deployments of SR have happened, and the standards that they rely on have 
not yet been published..
[DV] hence my point of pushing for P2MP like trees (ingress replication SID) in 
SR-MPLS/SRv6 network. This is a critical requirement for Bell Canada, at least 
..
[DV] Also, noticed that the work is already going on in the working group, as 
it is part of the SR policy architecture-draft – section 9.2 – which is an now 
a working group document.

This is unfortunate for those that have shipping implementations, or are 
relying on behaviours in their network.
[DV] yep, unfortunate, indeed. We don’t want to repeat the same mistake for 
ingress replication SID, don’t we ?

[..sniff]

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

Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein]

Robert, Paul and all,
I concur with Paul.
Domain-wide labels have been successfully purged from SR-MPLS for quite some 
time now, and, from my POV this purge is irreversible now.

My 2c.

Thumb typed by Sasha Vainshtein


From: Paul Mattes 
Sent: Friday, June 8, 2018 10:02:47 PM
To: Robert Raszuk; Alexander Vainshtein
Cc: spring@ietf.org; Xiejingrong; Michael McBride; Rob Shakir; Zafar Ali 
(zali); Eric C Rosen; Voyer, Daniel
Subject: RE: [spring] Updating the SPRING WG Charter

We don’t have domain-wide labels. We have domain-wide indices. The same index 
is represented with different label values by different hosts, depending on 
their SRGBs.

pdm

From: spring  On Behalf Of Robert Raszuk
Sent: Friday, June 8, 2018 9:59 AM
To: Alexander Vainshtein 
Cc: spring@ietf.org; Xiejingrong ; Michael McBride 
; Rob Shakir ; 
Zafar Ali (zali) ; Eric C Rosen ; Voyer, 
Daniel 
Subject: Re: [spring] Updating the SPRING WG Charter

Sasha,

> because usage of domain-wide labels has been discussed many times in the past 
> and rejected by the MPLS WG.

That comment I quite do not follow. Entire concept of SR-MPLS  is based on 
domain wide labels (distributed via IGP or OOB) and my description applies to 
SR based networks with both MPLS as well as v6 encap.

In other words we already have domain wide MPLS labels to indicate various 
types of segments. What I proposed would at most require perhaps new type which 
would embed node + replication function..

Thx,
R.


On Fri, Jun 8, 2018 at 4:53 PM, Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Robert,
I concur with Eric.

I also think that the scenarios you describe as relevant for 
SR-fan-out/SR-spray (“applications which on one side do not really require full 
multicast yet they would benefit with content to be send once from server and 
arrived at two or more caches”) strongly resembles IGMP/MLD Proxy applications 
(RFC 
4605<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4605=02%7C01%7Cpamattes%40microsoft.com%7C555c978a313441d9e0f508d5cd506e42%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636640667691087492=I1uK8l1aISD61f8E%2BH2Mt10v8RQ1W%2Bh2bS4pl%2BB%2BgOw%3D=0>).
 Is such an analogy correct?

Last but not least, it seems that your description of SR-fan-out mandates usage 
of domain-wide labels (mentioned by Eric as well_. If this is indeed so, I 
consider this as a stopper because usage of domain-wide labels has been 
discussed many times in the past and rejected by the MPLS WG.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: rras...@gmail.com<mailto:rras...@gmail.com> 
[mailto:rras...@gmail.com<mailto:rras...@gmail.com>] On Behalf Of Robert Raszuk
Sent: Thursday, June 7, 2018 7:04 PM
To: Eric C Rosen mailto:ero...@juniper.net>>
Cc: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; Xiejingrong 
mailto:xiejingr...@huawei.com>>; Michael McBride 
mailto:michael.mcbr...@huawei.com>>; Rob Shakir 
mailto:40google@dmarc.ietf.org>>; Zafar 
Ali (zali) mailto:z...@cisco.com>>; Voyer, Daniel 
mailto:daniel.vo...@bell.ca>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Eric,

The way I look at this is really not from the perspective of true dynamic 
multicast with tree building etc .. .I look at this as anchor points to 
replicate unicast flows into two or more endpoints maybe once or twice in 
entire domain.

So for sure if you would try to apply this technique to distribute traditional 
multicast there is tons of things which can go wrong and you are better off 
with BIER.

But there are applications which on one side do not really require full 
multicast yet they would benefit with content to be send once from server and 
arrived at two or more caches. Maybe we just don't have the right name for it 
in networking yet :)

Cheers,
R.


On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen 
mailto:ero...@juniper.net>> wrote:
On 6/7/2018 10:55 AM, Robert Raszuk wrote:
Imagine a segment with embedded meaning that packets received with such value X 
should be replicated to interfaces  Y & Z. Such decision can be configured from 
controller or locally computed.

Nothing there is per-path as well as nothing there is per flow or per multicast 
group. It is a local function.

How can you say "nothing there per-path"?  The label X represents a multicast 
tree, and thus constitutes per-path state.If some packets need to go to Y 
and Z, some need to go to Y, Z, and W, some need to go to Y, U, and V, etc., 
you obviously need a different label for each different multicast tree, and 
appropriate per-tree state.

Using a controller to set up multicast paths may be a good idea in some 
scenarios, but let's 

Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk]

​The below sentence I am going to frame next to the best quotes ever 
Thank you Paul !


We don’t have domain-wide labels. We have domain-wide indices. The same
> index is represented with different label values by different hosts,
> depending on their SRGBs.
>
>
>
> *pdm*
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Paul Mattes]

We don’t have domain-wide labels. We have domain-wide indices. The same index 
is represented with different label values by different hosts, depending on 
their SRGBs.

pdm

From: spring  On Behalf Of Robert Raszuk
Sent: Friday, June 8, 2018 9:59 AM
To: Alexander Vainshtein 
Cc: spring@ietf.org; Xiejingrong ; Michael McBride 
; Rob Shakir ; 
Zafar Ali (zali) ; Eric C Rosen ; Voyer, 
Daniel 
Subject: Re: [spring] Updating the SPRING WG Charter

Sasha,

> because usage of domain-wide labels has been discussed many times in the past 
> and rejected by the MPLS WG.

That comment I quite do not follow. Entire concept of SR-MPLS  is based on 
domain wide labels (distributed via IGP or OOB) and my description applies to 
SR based networks with both MPLS as well as v6 encap.

In other words we already have domain wide MPLS labels to indicate various 
types of segments. What I proposed would at most require perhaps new type which 
would embed node + replication function..

Thx,
R.


On Fri, Jun 8, 2018 at 4:53 PM, Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Robert,
I concur with Eric.

I also think that the scenarios you describe as relevant for 
SR-fan-out/SR-spray (“applications which on one side do not really require full 
multicast yet they would benefit with content to be send once from server and 
arrived at two or more caches”) strongly resembles IGMP/MLD Proxy applications 
(RFC 
4605<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4605=02%7C01%7Cpamattes%40microsoft.com%7C555c978a313441d9e0f508d5cd506e42%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636640667691087492=I1uK8l1aISD61f8E%2BH2Mt10v8RQ1W%2Bh2bS4pl%2BB%2BgOw%3D=0>).
 Is such an analogy correct?

Last but not least, it seems that your description of SR-fan-out mandates usage 
of domain-wide labels (mentioned by Eric as well_. If this is indeed so, I 
consider this as a stopper because usage of domain-wide labels has been 
discussed many times in the past and rejected by the MPLS WG.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: rras...@gmail.com<mailto:rras...@gmail.com> 
[mailto:rras...@gmail.com<mailto:rras...@gmail.com>] On Behalf Of Robert Raszuk
Sent: Thursday, June 7, 2018 7:04 PM
To: Eric C Rosen mailto:ero...@juniper.net>>
Cc: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; Xiejingrong 
mailto:xiejingr...@huawei.com>>; Michael McBride 
mailto:michael.mcbr...@huawei.com>>; Rob Shakir 
mailto:40google@dmarc.ietf.org>>; Zafar 
Ali (zali) mailto:z...@cisco.com>>; Voyer, Daniel 
mailto:daniel.vo...@bell.ca>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Eric,

The way I look at this is really not from the perspective of true dynamic 
multicast with tree building etc .. .I look at this as anchor points to 
replicate unicast flows into two or more endpoints maybe once or twice in 
entire domain.

So for sure if you would try to apply this technique to distribute traditional 
multicast there is tons of things which can go wrong and you are better off 
with BIER.

But there are applications which on one side do not really require full 
multicast yet they would benefit with content to be send once from server and 
arrived at two or more caches. Maybe we just don't have the right name for it 
in networking yet :)

Cheers,
R.


On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen 
mailto:ero...@juniper.net>> wrote:
On 6/7/2018 10:55 AM, Robert Raszuk wrote:
Imagine a segment with embedded meaning that packets received with such value X 
should be replicated to interfaces  Y & Z. Such decision can be configured from 
controller or locally computed.

Nothing there is per-path as well as nothing there is per flow or per multicast 
group. It is a local function.

How can you say "nothing there per-path"?  The label X represents a multicast 
tree, and thus constitutes per-path state.If some packets need to go to Y 
and Z, some need to go to Y, Z, and W, some need to go to Y, U, and V, etc., 
you obviously need a different label for each different multicast tree, and 
appropriate per-tree state.

Using a controller to set up multicast paths may be a good idea in some 
scenarios, but let's not pretend it doesn't create per-path state in the 
router.  Per-path (per-tree) is not the same as per-flow or per-group, of 
course, but that's true of any technique that aggregates flows into multicast 
tunnels.

Note also that if the label X is domain-wide unique and there is no RPF check, 
there is the possibility of nasty multicast loops.  These is some discussion of 
this in draft-zzhang-bess-bgp-multicast-controller-00.



___

Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk]

Sasha,

> because usage of domain-wide labels has been discussed many times in the
past and rejected by the MPLS WG.

That comment I quite do not follow. Entire concept of SR-MPLS  is based on
domain wide labels (distributed via IGP or OOB) and my description applies
to SR based networks with both MPLS as well as v6 encap.

In other words we already have domain wide MPLS labels to indicate various
types of segments. What I proposed would at most require perhaps new type
which would embed node + replication function.

Thx,
R.


On Fri, Jun 8, 2018 at 4:53 PM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Robert,
>
> I concur with Eric.
>
>
>
> I also think that the scenarios you describe as relevant for
> SR-fan-out/SR-spray (“applications which on one side do not really
> require full multicast yet they would benefit with content to be send once
> from server and arrived at two or more caches”) strongly resembles
> IGMP/MLD Proxy applications (RFC 4605
> <https://tools.ietf.org/html/rfc4605>). Is such an analogy correct?
>
>
>
> Last but not least, it seems that your description of SR-fan-out mandates
> usage of domain-wide labels (mentioned by Eric as well_. If this is indeed
> so, I consider this as a stopper because usage of domain-wide labels has
> been discussed many times in the past and rejected by the MPLS WG.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, June 7, 2018 7:04 PM
> *To:* Eric C Rosen 
> *Cc:* Alexander Vainshtein ;
> spring@ietf.org; Xiejingrong ; Michael McBride <
> michael.mcbr...@huawei.com>; Rob Shakir ;
> Zafar Ali (zali) ; Voyer, Daniel 
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Eric,
>
>
>
> The way I look at this is really not from the perspective of true dynamic
> multicast with tree building etc .. .I look at this as anchor points to
> replicate unicast flows into two or more endpoints maybe once or twice in
> entire domain.
>
>
>
> So for sure if you would try to apply this technique to distribute
> traditional multicast there is tons of things which can go wrong and you
> are better off with BIER.
>
>
>
> But there are applications which on one side do not really require full
> multicast yet they would benefit with content to be send once from server
> and arrived at two or more caches. Maybe we just don't have the right name
> for it in networking yet :)
>
>
>
> Cheers,
> R.
>
>
>
>
>
> On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen  wrote:
>
> On 6/7/2018 10:55 AM, Robert Raszuk wrote:
>
> Imagine a segment with embedded meaning that packets received with such
> value X should be replicated to interfaces  Y & Z. Such decision can be
> configured from controller or locally computed.
>
>
>
> Nothing there is per-path as well as nothing there is per flow or per
> multicast group. It is a local function.
>
>
> How can you say "nothing there per-path"?  The label X represents a
> multicast tree, and thus constitutes per-path state.If some packets
> need to go to Y and Z, some need to go to Y, Z, and W, some need to go to
> Y, U, and V, etc., you obviously need a different label for each different
> multicast tree, and appropriate per-tree state.
>
> Using a controller to set up multicast paths may be a good idea in some
> scenarios, but let's not pretend it doesn't create per-path state in the
> router.  Per-path (per-tree) is not the same as per-flow or per-group, of
> course, but that's true of any technique that aggregates flows into
> multicast tunnels.
>
> Note also that if the label X is domain-wide unique and there is no RPF
> check, there is the possibility of nasty multicast loops.  These is some
> discussion of this in draft-zzhang-bess-bgp-multicast-controller-00.
>
>
>
>
> 
> ___
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and then
> delete the original
> and all copies thereof.
> 
> ___
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein]

Dave, Rob and all,
I concur with Rob on this point.

Thumb typed by Sasha Vainshtein


From: Rob Shakir 
Sent: Thursday, June 7, 2018 8:10:18 PM
To: David Allan I
Cc: Alexander Vainshtein; Voyer, Daniel; Zafar Ali (zali); Michael McBride; 
Xiejingrong; spring@ietf.org
Subject: Re: [spring] Updating the SPRING WG Charter



On Thu, Jun 7, 2018 at 10:06 AM David Allan I 
mailto:david.i.al...@ericsson.com>> wrote:
Would not the existence of SRLB’s be an existence proof of per-path state at 
transit nodes in the SPRING architecture?

No - SRLBs are just label block allocations on that node. The labels allocated 
from an SRLB continue to be per-forwarding behaviour, not per-path. In the 
degenerate case, we might have a 1:1 mapping of forwarding behaviour to path, 
but this is implementation specific.

To demonstrate: consider the case that some programming entity creates a SID 
that means forward to SR label stacks 1, 2, 3 -- this can be used by any number 
of TE paths that are within that network.

r.

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[David Allan I]

Would not the existence of SRLB’s be an existence proof of per-path state at 
transit nodes in the SPRING architecture?

Dave

From: spring  On Behalf Of Alexander Vainshtein
Sent: Thursday, June 07, 2018 7:48 AM
To: Voyer, Daniel ; Zafar Ali (zali) ; 
Rob Shakir ; Michael McBride 

Cc: Xiejingrong ; spring@ietf.org
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,
I do not think that SPRING WG should deal with MC – possibly, excluding use of 
ingress replication for multicast.

This is based on what I see as the key element (highlighted) in definition of 
SPRING activities in the proposed charter:

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.

To the best of my understanding, the only way for SR to provide this 
functionality forf multicast (be it SR-MPLS or SRV6) is ingress replication 
using unicast SR paths. In particular, the framework defined in 
draft-allan<https://tools.ietf.org/html/draft-allan-spring-mpls-multicast-framework-03>
 explicitly requires per-path state in the replication points.

From my POV the only technology that allows MC traffic to traverse the transit 
nodes without per-path state in the transit nodes and without multiple copies 
of the packet crossing the same link is BIER.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Voyer, Daniel
Sent: Wednesday, June 6, 2018 11:20 PM
To: Zafar Ali (zali) mailto:z...@cisco.com>>; Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>; 
Michael McBride mailto:michael.mcbr...@huawei.com>>
Cc: Xiejingrong mailto:xiejingr...@huawei.com>>; 
spring@ietf.org<mailto:spring@ietf.org>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,

I support and agree w/ Zafar.

Multicast in SR is much needed and there is lots of development that needs to 
happen, whether for SRv6 or with SR-MPLS. The core architecture and development 
need to be included in this working group.

Thanks,
dan


From: "Zafar Ali (zali)" mailto:z...@cisco.com>>
Date: Wednesday, June 6, 2018 at 3:14 PM
To: Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>, 
Michael McBride mailto:michael.mcbr...@huawei.com>>
Cc: Xiejingrong mailto:xiejingr...@huawei.com>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>, "Zafar Ali (zali)" 
mailto:z...@cisco.com>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

The multicast in SR belongs to the same category as I highlighted in my last 
email. Just to repeat …

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

Specifically, multicast in SR is included in that list with the "Ingress 
replication SID (Tree SID /spray)" bullet (and support during the WG meeting) 
but is missing in the proposed charter text. So, I agree with Xiejingrong and 
Michael highlighting the same. There is already interest and agreement shown by 
the WG to include multicast in SR in the charter.

In the light of the above, please add a milestone for the WG to specify 
architecture, and the required protocol extensions for multicast in SR with 
MPLS and IPv6 data planes, including specification of the ingress replication 
SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly agree that the 
actual protocol extension work should be done at the WG that owns the protocol.

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride 
mailto:michael.mcbr...@huawei.com>>
Cc: Xiejingrong mailto:xiejingr...@huawei.com>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.
On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
mailto:michael.mcbr...@huawei.com>> wrote:
It would be helpful, while updating the charter, to state whether multicast in 
SR is in/out of scope in order to know which wg to take our future work.

I think this is impractical. If we state everything that is in or out of scope, 
we'll end up with a laundry list. The aim of the charter is to define clearly 
the work that the WG should focus on. It does not mean that we can never host 
discussion of indivi

Re: [spring] Updating the SPRING WG Charter

[Rob Shakir]

Zafar,

I intentionally left the list of milestones out of the mail. Clearly, we
need to agree the areas of work before we can break this down into
milestones. Equally, we have more flexibility in defining these since they
do not need to be reviewed by the IESG.

On Wed, Jun 6, 2018 at 12:14 PM Zafar Ali (zali)  wrote:

>
>
> At IETF101, you and Bruno presented a slide based on the WG feedback on
> the mailing list (
> https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01).
> During the Spring meeting, the WG agreed to add milestones to those items.
> In general, I see some milestones are not included in the proposed
> chartered text.
>
>
>
> Specifically, multicast in SR is included in that list with the "Ingress
> replication SID (Tree SID /spray)" bullet (and support during the WG
> meeting) but is missing in the proposed charter text. So, I agree with
> Xiejingrong and Michael highlighting the same. There is already interest
> and agreement shown by the WG to include multicast in SR in the charter.
>

This list was a recap of what had been discussed on the mailing list. It
was not the proposed exhaustive list. The preference in the charter text
(after much discussion) is to ensure that SPRING has a set of focus areas
to work on. This does not preclude interested individuals doing other work
- and even bringing it to SPRING. We can change the charter in the future
if new work comes up that isn't within the charter.

I would point out that the narrow scope that we (the SPRING WG) initially
had to deliver on has taken almost five years since we initially discussed
it (see this thread

regarding chartering STATUS as it was at the time). In this period of time,
real deployments of SR have happened, and the standards that they rely on
have not yet been published.  This is unfortunate for those that have
shipping implementations, or are relying on behaviours in their network.

I'd encourage us to focus on defining the problem spaces that are most
important and then work on those, deliver a standard, and then move on to
the next area. We can usually determine the importance/relevance of the
work to networks based on the number of interested parties - so the
intention of the list in the charter is to capture those elements which we
perceived to have widest interest in the charter. At some point, there will
be a line that is either "in the charter" or not, and some things below it
at the current time - yes, that might mean that one's favourite SR
application is not currently in the charter, but if there is significant
discussion on the list, and work items being brought as individual drafts,
we can always address this with Martin.

Thanks,
r.

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

Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk]

Hi Eric,

The way I look at this is really not from the perspective of true dynamic
multicast with tree building etc .. .I look at this as anchor points to
replicate unicast flows into two or more endpoints maybe once or twice in
entire domain.

So for sure if you would try to apply this technique to distribute
traditional multicast there is tons of things which can go wrong and you
are better off with BIER.

But there are applications which on one side do not really require full
multicast yet they would benefit with content to be send once from server
and arrived at two or more caches. Maybe we just don't have the right name
for it in networking yet :)

Cheers,
R.


On Thu, Jun 7, 2018 at 5:52 PM, Eric C Rosen  wrote:

> On 6/7/2018 10:55 AM, Robert Raszuk wrote:
>
> Imagine a segment with embedded meaning that packets received with such
> value X should be replicated to interfaces  Y & Z. Such decision can be
> configured from controller or locally computed.
>
> Nothing there is per-path as well as nothing there is per flow or per
> multicast group. It is a local function.
>
>
> How can you say "nothing there per-path"?  The label X represents a
> multicast tree, and thus constitutes per-path state.If some packets
> need to go to Y and Z, some need to go to Y, Z, and W, some need to go to
> Y, U, and V, etc., you obviously need a different label for each different
> multicast tree, and appropriate per-tree state.
>
> Using a controller to set up multicast paths may be a good idea in some
> scenarios, but let's not pretend it doesn't create per-path state in the
> router.  Per-path (per-tree) is not the same as per-flow or per-group, of
> course, but that's true of any technique that aggregates flows into
> multicast tunnels.
>
> Note also that if the label X is domain-wide unique and there is no RPF
> check, there is the possibility of nasty multicast loops.  These is some
> discussion of this in draft-zzhang-bess-bgp-multicast-controller-00.
>
>
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Updating the SPRING WG Charter

[Eric C Rosen]

On 6/7/2018 10:55 AM, Robert Raszuk wrote:
Imagine a segment with embedded meaning that packets received with 
such value X should be replicated to interfaces  Y & Z. Such decision 
can be configured from controller or locally computed.


Nothing there is per-path as well as nothing there is per flow or per 
multicast group. It is a local function.


How can you say "nothing there per-path"?  The label X represents a 
multicast tree, and thus constitutes per-path state.    If some packets 
need to go to Y and Z, some need to go to Y, Z, and W, some need to go 
to Y, U, and V, etc., you obviously need a different label for each 
different multicast tree, and appropriate per-tree state.


Using a controller to set up multicast paths may be a good idea in some 
scenarios, but let's not pretend it doesn't create per-path state in the 
router.  Per-path (per-tree) is not the same as per-flow or per-group, 
of course, but that's true of any technique that aggregates flows into 
multicast tunnels.


Note also that if the label X is domain-wide unique and there is no RPF 
check, there is the possibility of nasty multicast loops.  These is some 
discussion of this in draft-zzhang-bess-bgp-multicast-controller-00.




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

Re: [spring] Updating the SPRING WG Charter

[Robert Raszuk]

Hi Sasha,

I think there is technology to allow that.

Imagine a segment with embedded meaning that packets received with such
value X should be replicated to interfaces  Y & Z. Such decision can be
configured from controller or locally computed.

Nothing there is per-path as well as nothing there is per flow or per
multicast group. It is a local function.

Some folks call it SR-spray, I call it SR-fanout - but it does seems very
useful so I support keeping it in the proposed charter.

Many thx,
Robert,




On Thu, Jun 7, 2018 at 4:47 PM, Alexander Vainshtein <
alexander.vainsht...@ecitele.com> wrote:

> Hi all,
>
> I do not think that SPRING WG should deal with MC – possibly, excluding
> use of ingress replication for multicast.
>
>
>
> This is based on what I see as the key element (highlighted) in
> definition of SPRING activities in the proposed charter:
>
>
>
> 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
> .
>
>
>
> To the best of my understanding, the only way for SR to provide this
> functionality forf multicast (be it SR-MPLS or SRV6) is ingress replication
> using unicast SR paths. In particular, the framework defined in
> draft-allan
> <https://tools.ietf.org/html/draft-allan-spring-mpls-multicast-framework-03>
> explicitly requires per-path state in the replication points.
>
>
>
> From my POV the only technology that allows MC traffic to traverse the
> transit nodes without per-path state in the transit nodes and without
> multiple copies of the packet crossing the same link is BIER.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:  +972-549266302
>
> Email:   alexander.vainsht...@ecitele.com
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Voyer,
> Daniel
> *Sent:* Wednesday, June 6, 2018 11:20 PM
> *To:* Zafar Ali (zali) ; Rob Shakir  40google@dmarc.ietf.org>; Michael McBride 
> *Cc:* Xiejingrong ; spring@ietf.org
>
> *Subject:* Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi all,
>
>
>
> I support and agree w/ Zafar.
>
>
>
> Multicast in SR is much needed and there is lots of development that needs
> to happen, whether for SRv6 or with SR-MPLS. The core architecture and
> development need to be included in this working group.
>
>
>
> Thanks,
>
> dan
>
>
>
>
>
> *From: *"Zafar Ali (zali)" 
> *Date: *Wednesday, June 6, 2018 at 3:14 PM
> *To: *Rob Shakir , Michael McBride <
> michael.mcbr...@huawei.com>
> *Cc: *Xiejingrong , "spring@ietf.org" <
> spring@ietf.org>, "Zafar Ali (zali)" 
> *Subject: *Re: [spring] Updating the SPRING WG Charter
>
>
>
> Hi Rob,
>
>
>
> The multicast in SR belongs to the same category as I highlighted in my
> last email. Just to repeat …
>
>
>
> At IETF101, you and Bruno presented a slide based on the WG feedback on
> the mailing list (https://datatracker.ietf.org/
> meeting/101/materials/slides-101-spring-00-chairs-slides-01). During the
> Spring meeting, the WG agreed to add milestones to those items. In general,
> I see some milestones are not included in the proposed chartered text.
>
>
>
> Specifically, multicast in SR is included in that list with the "Ingress
> replication SID (Tree SID /spray)" bullet (and support during the WG
> meeting) but is missing in the proposed charter text. So, I agree with
> Xiejingrong and Michael highlighting the same. There is already interest
> and agreement shown by the WG to include multicast in SR in the charter.
>
>
>
> In the light of the above, please add a milestone for the WG to specify
> architecture, and the required protocol extensions for multicast in SR with
> MPLS and IPv6 data planes, including specification of the ingress
> replication SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly
> agree that the actual protocol extension work should be done at the WG that
> owns the protocol.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> *From: *spring  on behalf of Rob Shakir <
> robjs=40google@dmarc.ietf.org>
> *Date: *Monday, June 4, 2018 at 12:45 PM
> *To: *Michael McBride 
> *Cc: *Xiejingrong , "spring@ietf.org" <
> spring@ietf.org>
> *Subject: *Re: [spring] Updating the SPRING WG Charter
>
>
>
> Michael,
>
>
>
> Thanks for the comment.
>
> On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
> wrote:
>
>

Re: [spring] Updating the SPRING WG Charter

[Alexander Vainshtein]

Hi all,
I do not think that SPRING WG should deal with MC – possibly, excluding use of 
ingress replication for multicast.

This is based on what I see as the key element (highlighted) in definition of 
SPRING activities in the proposed charter:

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.

To the best of my understanding, the only way for SR to provide this 
functionality forf multicast (be it SR-MPLS or SRV6) is ingress replication 
using unicast SR paths. In particular, the framework defined in 
draft-allan<https://tools.ietf.org/html/draft-allan-spring-mpls-multicast-framework-03>
 explicitly requires per-path state in the replication points.

From my POV the only technology that allows MC traffic to traverse the transit 
nodes without per-path state in the transit nodes and without multiple copies 
of the packet crossing the same link is BIER.

My 2c,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Voyer, Daniel
Sent: Wednesday, June 6, 2018 11:20 PM
To: Zafar Ali (zali) ; Rob Shakir 
; Michael McBride 

Cc: Xiejingrong ; spring@ietf.org
Subject: Re: [spring] Updating the SPRING WG Charter

Hi all,

I support and agree w/ Zafar.

Multicast in SR is much needed and there is lots of development that needs to 
happen, whether for SRv6 or with SR-MPLS. The core architecture and development 
need to be included in this working group.

Thanks,
dan


From: "Zafar Ali (zali)" mailto:z...@cisco.com>>
Date: Wednesday, June 6, 2018 at 3:14 PM
To: Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>, 
Michael McBride mailto:michael.mcbr...@huawei.com>>
Cc: Xiejingrong mailto:xiejingr...@huawei.com>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>, "Zafar Ali (zali)" 
mailto:z...@cisco.com>>
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

The multicast in SR belongs to the same category as I highlighted in my last 
email. Just to repeat …

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

Specifically, multicast in SR is included in that list with the "Ingress 
replication SID (Tree SID /spray)" bullet (and support during the WG meeting) 
but is missing in the proposed charter text. So, I agree with Xiejingrong and 
Michael highlighting the same. There is already interest and agreement shown by 
the WG to include multicast in SR in the charter.

In the light of the above, please add a milestone for the WG to specify 
architecture, and the required protocol extensions for multicast in SR with 
MPLS and IPv6 data planes, including specification of the ingress replication 
SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly agree that the 
actual protocol extension work should be done at the WG that owns the protocol.

Thanks

Regards … Zafar

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Rob Shakir 
mailto:robjs=40google@dmarc.ietf.org>>
Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride 
mailto:michael.mcbr...@huawei.com>>
Cc: Xiejingrong mailto:xiejingr...@huawei.com>>, 
"spring@ietf.org<mailto:spring@ietf.org>" 
mailto:spring@ietf.org>>
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.
On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
mailto:michael.mcbr...@huawei.com>> wrote:
It would be helpful, while updating the charter, to state whether multicast in 
SR is in/out of scope in order to know which wg to take our future work.

I think this is impractical. If we state everything that is in or out of scope, 
we'll end up with a laundry list. The aim of the charter is to define clearly 
the work that the WG should focus on. It does not mean that we can never host 
discussion of individual drafts if they are relevant. If there are 
requirements, we can always recharter if something new becomes the highest 
priority for the industry w.r.t SR.

Kind regards,
r.

___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
_

Re: [spring] Updating the SPRING WG Charter

[Voyer, Daniel]

Hi all,

I support and agree w/ Zafar.

Multicast in SR is much needed and there is lots of development that needs to 
happen, whether for SRv6 or with SR-MPLS. The core architecture and development 
need to be included in this working group.

Thanks,
dan


From: "Zafar Ali (zali)" 
Date: Wednesday, June 6, 2018 at 3:14 PM
To: Rob Shakir , Michael McBride 

Cc: Xiejingrong , "spring@ietf.org" , 
"Zafar Ali (zali)" 
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Rob,

The multicast in SR belongs to the same category as I highlighted in my last 
email. Just to repeat …

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

Specifically, multicast in SR is included in that list with the "Ingress 
replication SID (Tree SID /spray)" bullet (and support during the WG meeting) 
but is missing in the proposed charter text. So, I agree with Xiejingrong and 
Michael highlighting the same. There is already interest and agreement shown by 
the WG to include multicast in SR in the charter.

In the light of the above, please add a milestone for the WG to specify 
architecture, and the required protocol extensions for multicast in SR with 
MPLS and IPv6 data planes, including specification of the ingress replication 
SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly agree that the 
actual protocol extension work should be done at the WG that owns the protocol.

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride 
Cc: Xiejingrong , "spring@ietf.org" 
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.
On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
mailto:michael.mcbr...@huawei.com>> wrote:
It would be helpful, while updating the charter, to state whether multicast in 
SR is in/out of scope in order to know which wg to take our future work.

I think this is impractical. If we state everything that is in or out of scope, 
we'll end up with a laundry list. The aim of the charter is to define clearly 
the work that the WG should focus on. It does not mean that we can never host 
discussion of individual drafts if they are relevant. If there are 
requirements, we can always recharter if something new becomes the highest 
priority for the industry w.r.t SR.

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

Re: [spring] Updating the SPRING WG Charter

[Zafar Ali (zali)]

Hi Rob,

The multicast in SR belongs to the same category as I highlighted in my last 
email. Just to repeat …

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

Specifically, multicast in SR is included in that list with the "Ingress 
replication SID (Tree SID /spray)" bullet (and support during the WG meeting) 
but is missing in the proposed charter text. So, I agree with Xiejingrong and 
Michael highlighting the same. There is already interest and agreement shown by 
the WG to include multicast in SR in the charter.

In the light of the above, please add a milestone for the WG to specify 
architecture, and the required protocol extensions for multicast in SR with 
MPLS and IPv6 data planes, including specification of the ingress replication 
SIDs (e.g., Tree SID, Spray). Nonetheless, I wholeheartedly agree that the 
actual protocol extension work should be done at the WG that owns the protocol.

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

Date: Monday, June 4, 2018 at 12:45 PM
To: Michael McBride 
Cc: Xiejingrong , "spring@ietf.org" 
Subject: Re: [spring] Updating the SPRING WG Charter

Michael,

Thanks for the comment.
On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
mailto:michael.mcbr...@huawei.com>> wrote:
It would be helpful, while updating the charter, to state whether multicast in 
SR is in/out of scope in order to know which wg to take our future work.

I think this is impractical. If we state everything that is in or out of scope, 
we'll end up with a laundry list. The aim of the charter is to define clearly 
the work that the WG should focus on. It does not mean that we can never host 
discussion of individual drafts if they are relevant. If there are 
requirements, we can always recharter if something new becomes the highest 
priority for the industry w.r.t SR.

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

Re: [spring] Updating the SPRING WG Charter

[Zafar Ali (zali)]

Hi Rob,

Re: Linda comment on SR assisted SD-WAN.

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

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


  *   Interactions between overlay/applications and optimized underlay
 *   E.g. SR-assisted SD-WAN, path awareness

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

Thanks

Regards … Zafar

From: spring  on behalf of Rob Shakir 

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

Hi Linda,

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

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

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

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

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

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

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

 *snip*

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

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

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

Thanks for the comments.

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

Re: [spring] Updating the SPRING WG Charter

[Rob Shakir]

Michael,

Thanks for the comment.

On Mon, Jun 4, 2018 at 9:42 AM Michael McBride 
wrote:

> It would be helpful, while updating the charter, to state whether
> multicast in SR is in/out of scope in order to know which wg to take our
> future work.
>

I think this is impractical. If we state everything that is in or out of
scope, we'll end up with a laundry list. The aim of the charter is to
define clearly the work that the WG should focus on. It does not mean that
we can never host discussion of individual drafts if they are relevant. If
there are requirements, we can always recharter if something new becomes
the highest priority for the industry w.r.t SR.

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

Re: [spring] Updating the SPRING WG Charter

[Michael McBride]

Hi Rob,

It would be helpful, while updating the charter, to state whether multicast in 
SR is in/out of scope in order to know which wg to take our future work.

Thanks,
mike

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Monday, June 04, 2018 9:12 AM
To: Xiejingrong 
Cc: spring@ietf.org
Subject: Re: [spring] Updating the SPRING WG Charter

Hi Jingrong,
On Sun, Jun 3, 2018 at 7:44 PM Xiejingrong 
mailto:xiejingr...@huawei.com>> wrote:
Will SPRING consider multicast/BIER being included ? These are some reasons I 
am thinking about:
(1) multicast/multipoint-transfer is always a requirement for internet service, 
and is always requiring some unicast technology as a precursor.
(2) there is already a similar WG BIER to considering the similar stateless 
solution for multicast for long-term.
(3) there is already some consideration about multipoint SR in 
segment-routing-policy draft for a long time.
(4) there is already some consideration about combining BIER and SR in 
bier-6man-encapsulation draft.
(5) it had been mentioned in ietf101 London to consider cooperating with BIER 
for some purpose.

robjs> IMHO, if BIER leverages SR work this should be in liaison with SPRING, 
but I do not expect there to be any BIER related work in SPRING itself. If this 
needs changes to dataplanes, then the relevnat working group (mpls, or 6man) 
should be involved too.

robjs> It is my personal opinion that the SR-TE policy draft needs to be a 
constrained set of problems. It had become a collect-your-use-case document. 
Part of the ask of breaking the document down is so that we can produce a 
clear, succinct set of documents. Until such time as there are concrete 
proposals on multicast in SR that SPRING needs to consider (i.e., require a new 
functional specification, ratheror architectural extension) then I would aim to 
err on the side of keeping the charter clear, rather than collecting all 
possible use cases in it.

robjs> Please disagree with me if there is a benefit to having this in the 
charter that I'm missing.

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

Re: [spring] Updating the SPRING WG Charter

[Xiejingrong]

Hi Bob,

Will SPRING consider multicast/BIER being included ? These are some reasons I 
am thinking about:
(1) multicast/multipoint-transfer is always a requirement for internet service, 
and is always requiring some unicast technology as a precursor.
(2) there is already a similar WG BIER to considering the similar stateless 
solution for multicast for long-term.
(3) there is already some consideration about multipoint SR in 
segment-routing-policy draft for a long time.
(4) there is already some consideration about combining BIER and SR in 
bier-6man-encapsulation draft.
(5) it had been mentioned in ietf101 London to consider cooperating with BIER 
for some purpose.

Thanks,
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Rob Shakir
Sent: Friday, June 01, 2018 9:06 AM
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). 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 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 The inter-working between SRv6 and SR-MPLS.

o Using SR 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 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 

Re: [spring] Updating the SPRING WG Charter

[James N Guichard]

Hi Rob,

Please can you add that the SPRING WG will cooperate and collaborate with the 
SFC WG for service function chaining.

Thanks!

Jim

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, June 01, 2018 12:44 PM
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.

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.

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.

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 IPv6 dataplane for SR and associated OAM extensions
 * lsr on OSPF and IS-IS extensions to flood SPRING-related information
[jeff] in RIFT we plan to support SR as well
* 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] 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 O

Re: [spring] Updating the SPRING WG Charter

[Jeff Tantsura]

Hi Rob,

 

Looks good, few additions, please see inline 

 

Cheers,

Jeff

From: spring  on behalf of Rob Shakir 

Date: Friday, June 1, 2018 at 09:05
To: SPRING WG List 
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.

 

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.

 

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.

 

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 IPv6 dataplane for SR and associated OAM extensions

 * lsr on OSPF and IS-IS extensions to flood SPRING-related information

[jeff] in RIFT we plan to support SR as well

* idr for BGP extensions

 * bess for VPN control plane

 * pce on extensions to communicate with an external entity to compute and 
program SPRING paths

 * teas on generic traffic engineering architecture

[jeff] rtgwg for fast convergence related topics

 

Please comment on the contents of the charter text on the list.

 

Thanks,

Bruno & Rob

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