Bruno and all,
At the first glance looks just fine to me!
Thumb typed by Sasha Vainshtein
________________________________
From: spring <spring-boun...@ietf.org> on behalf of bruno.decra...@orange.com
<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 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 the list.
Thanks,
Bruno & Rob
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
___________________________________________________________________________
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
