Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.
Apologies that this review comes well after the end of IETF last call, however,
I have only recently received the request for review.
Adrian
====
Document: draft-ietf-spring-ipv6-use-cases-10.txt
Reviewer: Adrian Farrel
Review Date: 8th June 2017
IETF LC End Date: 4th May 2017
Intended Status: Informational
Summary:
I have some minor concerns about this document that I think should be resolved
before publication.
Comments:
This document supplies primary use cases for SRv6 in a variety of environments.
While originally intended to help motivate the SR architecture, this document
now provides a set of use cases that explain how the technology might be used.
The document is easy to read and should be published as a helpful explanation
of how SRv6 could be used.
====
Major Issues:
None found.
====
Minor Issues:
While I think this document is useful and should be published, the
motivation given in the Abstract suggests that the Architecture is
dependent on this draft. That is clearly not the case (since that I-D
has already progressed through IETF last call and only makes Informative
reference to this document). That shouldn't be an issue of any
significance but probably some rewording is needed, such as...
The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing can be used to steer packets through
an IPv6 or MPLS network using the source routing paradigm.
This document illustrates some use cases for Segment Routing in an
IPv6 environment.
---
Terminology...
The document mixes "SPRING" and "spring". I think it should always be
upper case.
But I also think that the balance between "SPRING" and "Segment Routing"
may reflect the age of the document. That maybe doesn't need to be
fixed, but the document might align better with other documents if it
was.
Finally, there is some confusion about what a "segment" is. I think we
previously had this conversation with regard to
draft-ietf-idr-bgp-prefix-sid and concluded that:
A segment represents either a topological instruction such
as "go to prefix P following shortest path" or a service instruction
(e.g.: "pass through deep packet inspection").
A segment is identified through a Segment Identifier (SID).
---
I fully believe in the value of running SR in an IPv6 network, but I
think that some of the motivation provided in the Introduction is
dubious. The text reads...
In addition there are cases where the operators could have made the
design choice to disable IPv4, for ease of management and scale
(return to single-stack) or due to an address constraint, for example
because they do not possess enough IPv4 addresses resources to number
all the endpoints and other network elements on which they desire to
run MPLS.
In such scenario the support for MPLS operations on an IPv6-only
network would be required. However today's IPv6-only networks are
not fully capable of supporting MPLS.
This point does not motivate SRv6 since today's IPv6-only networks are
also not fully capable of supporting SRv6.
There is ongoing work in the
MPLS Working Group, described in [RFC7439] to identify gaps that must
be addressed in order to allow MPLS-related protocols and
applications to be used with IPv6-only networks.
RFC 7439 is now over two years old. Work on filling the gaps identified
began when draft-mpls-ipv6-only-gap was first published in 2013. In the
time since then a number of RFCs have been published to fill the gaps
and implementations have been upgraded.
This is an another
example of scenario where a solution relying on IPv6 without
requiring the use of MPLS could represent a valid option to solve the
problem and meet operators' requirements.
My conclusion is that this document is trying to oversell the use of
SR in an IPv6 network where no such sale needs to be made. The result is
that it appears to disparage MPLS where it should be enough to say that
a choice can be made, and then lay out the use cases where that choice
is made and explain how the network works when the choice is made.
I would suggest simply removing these paragraphs with the result of a
stronger statement of use rather than an arguable statement of
motivation.
---
Section 1
3. There is a need or desire to remove routing state from any node
other than the source, such that the source is the only node that
knows and will know the path a packet will take, a priori
I think this is a little confused. Obviously, you still have routing
state in the nodes within the network for everything other than
adjacency SIDs. I think that what you are removing from the network is
path state (or control plane signaling state). How about...
3. There is a need or desire to remove as much state as possible
from the nodes in the network such that the source is the only
node that knows the path a packet will take through the network.
---
Section 1
I'm not really convinced by the fourth bullet. It's true that IP
addresses can be aggregated so that one advertisement can carry a prefix
but this also applies to address advertisements that carry MPLS SIDs.
I think you are probably making a point about how an end-to-end SID can
be routed across a network without the need for a SID stack, but it is a
bit hard to extract from the text.
---
The start of Section 2 has the same issue as the Abstract. I suggest...
OLD
This section will describe some scenarios where MPLS may not be
present and it will highlight the need for the spring architecture to
take them into account.
The use cases described in the section do not constitute an
exhaustive list of all the possible scenarios; this section only
includes some of the most common envisioned deployment models for
IPv6 Segment Routing. In addition to the use cases described in this
document the spring architecture should be able to be applied to all
the use cases described in [RFC7855] for the spring MPLS data plane,
when an IPv6 data plane is present.
NEW
This section describes some scenarios where segment routing is
applicable in an IPv6 environment.
The use cases described in the section do not constitute an
exhaustive list of all the possible scenarios: this section only
includes some of the most common envisioned deployment models for
IPv6 Segment Routing. In addition to the use cases described in this
document the spring architecture could be able to be applied to all
the use cases described in [RFC7855] for the spring MPLS data plane,
when an IPv6 data plane is present.
====
Nits:
You'll need to expand some abbreviations like QAM and DOCSIS.
You can check https://www.rfc-editor.org/materials/abbrev.expansion.txt
---
Section 2.3
OLD
In such scenario Segment Routing
NEW
In such scenarios, Segment Routing
END
---
OLD
2.4. SPRING in the Content Delivery Networks
NEW
2.4. SPRING in Content Delivery Networks
END
---
OLD
2.5. SPRING in the Core networks
NEW
2.5. SPRING in Core Networks
END
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
