Subject: [spring] WG Review: Source Packet Routing in Networking (spring)

From: The IESG <[email-masked]>
Date: Mon, 10 Sep 2018 09:25:00 -0700

The Source Packet Routing in Networking (spring) WG in the Routing Area of
the IETF is undergoing rechartering. The IESG has not made any determination
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing
list ([email-masked]) by 2018-09-20.

Source Packet Routing in Networking (spring)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Rob Shakir <[email-masked]>
  Bruno Decraene <[email-masked]>

Assigned Area Director:
  Martin Vigoureux <[email-masked]>

Routing Area Directors:
  Alvaro Retana <[email-masked]>
  Deborah Brungard <[email-masked]>
  Martin Vigoureux <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/spring
  Archive: https://mailarchive.ietf.org/arch/browse/spring/

Group page: https://datatracker.ietf.org/group/spring/

Charter: https://datatracker.ietf.org/doc/charter-ietf-spring/

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 of, and specify extensions of Segment Routing
technologies.

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 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 typically operates within
a single trust domain which requires the enforcement of a strict boundary
and preventing Segment Routing packets from entering the trusted domain
from the untrusted exterior.  Certain deployments may however involve
multiple trust domains which in turn may imply the use of cross/inter
domain segments. Risk models associated with these various scenarios may
necessitate the use of a cryptographic integrity checks to validate that
the segment list is provided by an authorised entity.
As is customary in the Routing Area, the SPRING WG will also identify and
address any other security considerations introduced by the technologies
it defines; addressing such considerations may require the introduction of
new functionality in protocols leveraged for Source Routing, in which case
the SPRING WG will formulate requirements to be considered by the
appropriate WG for that work.  SPRING technologies may be deployed in
environments spanning a range of risk and threat models, which may impact
both the security considerations and the requirements place on other
protocols in order to support Source Routing protocols.

The technologies SPRING WG defines may be applicable to both centralised
and distributed path computation.

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

-----------------------------------------------------------------------
Milestones:
SR-MPLS sent to IESG by October 2018
SR-MPLS configuration YANG model sent to IESG by December 2018
MPLS anycast sent to IESG by October 2018
SR-TE policy sent to IESG by <mid-2019>
SR policies YANG model sent to IESG by December 2019
SR-MPLS OAM sent to IESG by <mid-2019>
SR-MPLS Performance Measurement to IESG by <mid-2019>
SR-IPv6 OAM sent to IESG by <mid-2019>
Stateless service chaining with SR sent to IESG by <end of 2019>
SRv6 Network Programming to IESG by <end of 2019>

---

From: <[email-masked]>
Date: Tue, 11 Sep 2018 06:47:47 +0000

Hi Bruno,

one comment on the proposed agenda,

<snip>

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

[RG] The multicast part has been agreed. I personally am not interested in work on "new types of segments mapping to local forwarding resources". This solution likely requires maintaining state in core nodes. Such a solution makes sense, if resources are scarce and different products compete for bandwidth in a range similar as the core network to be sliced itself. This isn't the case in most networks today. If this work is to be scheduled, I'd prefer to wait until there are use cases requiring it. I've asked for those, but didn't yet receive a response. 

Should "new types of segments mapping to local forwarding resources" be a multicast requirement only, my question is, whether this is a new requirement and needs to be maintained. I'm not a multicast expert but think to recall, that providing separate forwarding resources to replicated packets within router hardware is state of  the art. If that's the case, what's new here?

If "new types of segments mapping to local forwarding resources" is limited to user access interfaces of SR domain edge nodes, the text should say so. 

Regards,

Ruediger

---

From: <[email-masked]>
Date: Tue, 11 Sep 2018 07:44:25 +0000

Hi Ruediger,

Thanks for the feedback and comments.

On a process standpoint, note that the charter has already been sent to the IESG for review https://datatracker.ietf.org/doc/charter-ietf-spring/history/

> From: [email-masked] [mailto:[email-masked]]
 > Sent: Tuesday, September 11, 2018 8:48 AM
> 
 > Hi Bruno,
 > 
 > o New types of segments mapping to forwarding behaviour (e.g., local ingress replication, local
 > forwarding resources, a pre-existing replication structure) if needed for new usages.
 > 
 > [RG] The multicast part has been agreed. I personally am not interested in work on "new types
 > of segments mapping to local forwarding resources". This solution likely requires maintaining
 > state in core nodes. Such a solution makes sense, if resources are scarce and different
 > products compete for bandwidth in a range similar as the core network to be sliced itself. This
 > isn't the case in most networks today. If this work is to be scheduled, I'd prefer to wait until there
 > are use cases requiring it. I've asked for those, but didn't yet receive a response.
 > 
 > Should "new types of segments mapping to local forwarding resources" be a multicast
 > requirement only, my question is, whether this is a new requirement and needs to be
 > maintained. I'm not a multicast expert but think to recall, that providing separate forwarding
 > resources to replicated packets within router hardware is state of  the art. If that's the case,
 > what's new here?
 > 
 > If "new types of segments mapping to local forwarding resources" is limited to user access
 > interfaces of SR domain edge nodes, the text should say so.

The work item is: "o New types of segments mapping to forwarding behaviour if needed for new usages."
" (e.g., local ingress replication, local forwarding resources, a pre-existing replication structure)" are possible examples. Their purpose is to give a better practical idea of what "forwarding behavior" could represent. It's not a statement that the WG must deliver on "local forwarding ressources" .

As a side note, regarding specifically "new types of segments mapping to local forwarding resources", I think one could argue that https://tools.ietf.org/html/draft-ietf-isis-l2bundles-07 could fall into this. But the discussion is moot as this work item has already been carried out by the IS-IS WG, independently of this SPRING charter.

Regards,
--Bruno

 > Ruediger

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Tue, 11 Sep 2018 14:02:52 +0000

Hi Bruno,

I admit that I had ample opportunity to earlier comment on the proposed charter statement and didn't. So I don't re-open discussion now.

I trust you and Rob to interpret the charter item "New types of segments mapping to forwarding behaviour if needed for new usages" not as a statement allowing to get WG status for drafts offering solutions without prior describing the problems to be solved. 

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 11. September 2018 09:44
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]
Betreff: RE: [spring] WG Review: Source Packet Routing in Networking (spring)

Hi Ruediger,

 > o New types of segments mapping to forwarding behaviour (e.g., local ingress replication, local  > forwarding resources, a pre-existing replication structure) if needed for new usages.
 >
 > [RG] The multicast part has been agreed. I personally am not interested in work on "new types  > of segments mapping to local forwarding resources". This solution likely requires maintaining  > state in core nodes. Such a solution makes sense, if resources are scarce and different  > products compete for bandwidth in a range similar as the core network to be sliced itself. This  > isn't the case in most networks today. If this work is to be scheduled, I'd prefer to wait until there  > are use cases requiring it. I've asked for those, but didn't yet receive a response.
 >
 > Should "new types of segments mapping to local forwarding resources" be a multicast  > requirement only, my question is, whether this is a new requirement and needs to be  > maintained. I'm not a multicast expert but think to recall, that providing separate forwarding  > resources to replicated packets within router hardware is state of  the art. If that's the case,  > what's new here?
 >
 > If "new types of segments mapping to local forwarding resources" is limited to user access  > interfaces of SR domain edge nodes, the text should say so.

Regards,
--Bruno

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

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