Il 2021-10-14 01:24, John Scudder ha scritto:
Hi Robert,
My question doesn’t have anything to do with “classic ASIC design”.
Indeed if you look at the definitions I supplied they don’t say anything
at all about how the router is implemented, the nature of the control
plane including whether there is one, and indeed are very broad. I would
say they are general enough to encompass everything you described.
As best I can tell, “adding new flavo[u]rs” or “adding new behaviors” is
just a different way of saying “making a change to the local, per-router
function that determines how a datagram arriving on a router input port
is forwarded to a router output port”. That is to say, by definition it
is a change to the forwarding plane.
I tried to motivate this with the for-instance in my fourth paragraph:
can my plain-vanilla RFC 8754 network successfully forward a packet that
uses cSIDs? Or does it need new software, at the nodes identified by the
SIDs contained in the cSID, in order to supply support for the “new
flavor” or “new behavior”? If it needs new software, then it seems
self-evident to me that it’s a change to the forwarding plane — it
“looks like a duck, swims like a duck, and quacks like a duck”.[*]
Hi John,
I agree that the statement "this solution does not require any SRH data
plane change" needs to be clarified, also because there is no formal
definition of a "data plane", hence it is even more vague the "SRH data
plane".
My understanding of "SRH data plane" here is the combination of RFC 8754
AND RFC 8986 (SRv6 Network Programming).
The second sentence in the draft says:
"SRv6 Network Programming [RFC8986] defines a framework to build a
network program with topological and service segments carried in a
Segment Routing header (SRH) [RFC8754]."
So I think the context of the draft is SRv6 Network programming... in
this context the basic idea is that you can add new features (i.e. new
instructions) in specific nodes and add the "network program" in the
packet header so that you know in advance which nodes will execute which
instructions.
In this way you can include in your network a mix of "legacy" RFC 8754
nodes (that do not need to implement the new features) and nodes that
support the new features (e.g. the CSID flavours).
I think this gives a reasonable interpretaion of "does not require any
SRH data plane change"... though I agree it could be better explained
ciao
Stefano
Thanks,
—John
[*] https://en.wikipedia.org/wiki/Duck_test
<https://en.wikipedia.org/wiki/Duck_test>
On Oct 13, 2021, at 6:57 PM, Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>> wrote:
Hi John,
I think the crux of the matter is indeed in definition of "SRH data
plane". So let me present my own personal understanding of it.
Clearly SRH external format does not change so hardware's ability to
read SRH remains intact. IPv6 packet's header also can be read and
processed by network elements which have no idea about cSIDs so that
as well is not questionable.
Now your definition of data plane is sound if you consider traditional
data planes of network elements when control plane input set's
forwarding behaviour.
Well in SRH as you know we have SIDs which inside may contain
functions. So forwarding behavior is not pre programmed from control
plane, but can and often is embedded in the actual packets. That is
what real network programming is all about. And each function can have
zoo of also nested arguments all resulting in different forwarding
outcome.
With such definition of SRH data plane I do not see anything new in
adding few new flavours to existing behaviours or even adding new
behaviours.
Now the question is do we all see SRH data plane in the same way.
Maybe it is way ahead of our times and classic ASIC design ? And I am
in no way judging here if this is good or bad - I am just observing
the facts and already published RFCs.
Many thx,
Robert
PS. And I do agree with your inline comment that cSIDs should be
possible to be used without SRH if no special functions are needed at
each segment endpoint.
On Thu, Oct 14, 2021 at 12:28 AM John Scudder <j...@juniper.net
<mailto:j...@juniper.net>> wrote:
Hi Folks,
I’m struggling with the claim repeated throughout the beginning of
draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1,
§3) that “this solution does not require any SRH data plane change”.
I’m not aware of a standardized formal definition of “data plane”,
it seems to follow Justice Stewart’s maxim of “I know it when I
see it”. However, here’s an attempt, cribbed from some Washington
University course slides: a “local, per-router function that
determines how a datagram arriving on a router input port is
forwarded to a router output port”. Seems reasonable.
I also am not aware of a standardized formal definition of the
term “SRH data plane”, in fact this draft, its predecessors, some
associated blog posts, and Clarence’s dissertation, are the only
places a search finds the phrase (but it’s not formally defined in
any of them). So I’m just going to assume it means the data plane,
as applied to packets that include an SRH. (I’m not sure why we
should disregard packets that are encoded using NEXT-C-SID that
omit the SRH, but let’s overlook that for now.)
If this solution does not require any SRH data plane change,
presumably it would be true that if I take a packet that includes
an SRH and place within it a series of SIDs encoded with (for
example) the REPLACE-C-SID flavor, then that packet would be able
to successfully traverse a network of routers that support plain
vanilla RFC 8754. That is, it would arrive at its first hop router
which according to a local, per-router function, would determine
how to take the datagram arriving on the router input port and
forward it to (the correct) router output port. Then that process
would be repeated across the rest of the network.
But that is patently incorrect: when it’s delivered to the first
hop, the plain vanilla RFC 8754 router will be unable to apply the
REPLACE-C-SID behavior, and forwarding to the next hop will fail.
It seems that a different local, per-router function is required
(in fact, the local, per-router function defined in the draft) in
order for the forwarding to succeed. By the definitions I’m using
here, that is exactly a data plane change.
What, precisely, is then being claimed?
Thanks,
—John
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY
http://netgroup.uniroma2.it/Stefano_Salsano/
E-mail : stefano.sals...@uniroma2.it
Cell. : +39 320 4307310
Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
