I am not sure I understand the answer. I do see that the local
processing is described in the draft. But that is not what I am asking.
I am going to try to simplify the conventions to ask the question. I
will list SIDs in the order they will be visited. And mark G-SID-X for
a global SID, and R-SID-X for a replication SID.
Suppose the stack looks like
G-SID-1
R-SID-1
G-SID-2
G-SID-3
R-SID-2
G-SID-4
So the packet gets delivered to the node identified by G-SID-1. Great.
That node sees an R-SID which it understands. So presumably it
replicates the packet, and sends the packet (possibly with some
prepended labels, presumably different prepended labels for different
destination, controlled by policy. No problem with that part.)
Now each of the packets geet to the end of the prepended labels, and
each copy sees G-SID-2. At which point all of these various nodes that
have received copies of the packet all send it to the node identified by
G-SID-2. Huh? We just bombarded a node with useless and potentially
harmful copies of the packet. then all those copies go to G-SID-3,
which then processes R-SID-2, and replicates each and every copy to some
set of destinations. Which then eventually bombard the node identified
by G-SID-4.
If the document said that the replication SID when it appears in the
stack must be the last SID in the stack, and was either terminal for SID
processing or was a binding SID, the above problem would be avoided.
But the draft does not say that. Nor does your reply.
Is there some other way this explosion is avoided? This seems to need
to be described in the SPRING draft in order for any of us to understand
if the approach is what we want as a starting point. just the idea of
replication segments is not, in my personal view, enough clarity or
value to be adopted as a working group document.
Yours,
Joel
On 7/1/2020 12:06 PM, Rishabh Parekh wrote:
Joel,
Your request was not "lost", but it fell between the cracks :)
Anyway, responses inline.
On Mon, Jun 29, 2020 at 3:17 PM Joel M. Halpern <j...@joelhalpern.com> wrote:
I asked the authors a version of this question, but apparently my
request got lost.
For now, this is speaking as an individual. And I sincerely hope that I
am merely missing something obvious.
I can not figure out from the current draft how the replication segment
works in a SID (or label) stack.
Is there an unstated requirement that the segment must be the last one
in the stack?
If not, how is a global SID after teh replication SID understood?
[RP] Replication SID does not need to be the last segment in the
stack. Although Section 2 of draft does not state this explicitly, If
there are other non-replication SIDs following the Replication SID,
the NEXT operation at a downstream node of the segment should process
those SIDs as normal.
Or is a replication SID implicitly also a binding SID, replacing the
rest of the stack no matter where it is in the stack?
In which case it is implicitly effectively last?
[RP] At a root or a Replication SID, when the active segment is a
Replication SID, it does act like a Binding SID in that it steers the
packet into the Replication segment towards downstream nodes. Note
that additional SIDs might be added on top of the Replication SID to
steer the packet from Root to a given downstream node. The Replication
SID will be at bottom of any such SIDs added to steer the packet, but
again it does not have to be the bottom most SID in the stack.
Given taht a replication segment is qualified to a node, what happens if
there is more than one in a stack? Is it ignored when it hits a node it
does not apply to?
[RP] On a given node, if an active SID in the stack is a Replication
SID that the node does not understand, it cannot process the packet.
This would be similar to any other kind of SID for which a node does
not have any state.
Do I believe this can be made to work? Yes.
But I can not understand how the WG could adopt the work with its
current lack of clarity.
And this appears to me to be fundamental enough stuff that it can't be
left to documents in other WGs. It seems central to the definition and
processing of replication SIDs.
[RP] Section 2 does specify behavior associated with Replication SID
at different nodes in terms of PUSH, CONTINUE or NEXT operations. If
it is not clear, we can enhance the text.
Yours,
Joel - speaking as a participant
_______________________________________________
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
