As I understand the words, the SRv6 dataplane is that part of the IPv6
dataplane that is using SRv6. (If it were not for reduced mode, it
would be that part that uses the SRH.)
Yours,
Joel
On 11/5/2021 3:26 PM, Robert Raszuk wrote:
Ok Joel - final question from me on this.
Do you believe
In the shared memory case, indeed, it is very reasonable to look at the
proxy as an arm of the function.
In SFC, we do look at it (the proxy as an arm of the SF) that way more
generally. We can do that because the SFC architecture calls that out.
Given that the other cases do involve network
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,
Thank you Jie. Yes, I think it would help to do what you describe,
reducing those discussions in this document.
Yours,
Joel
On 6/23/2020 3:08 AM, Dongjie (Jimmy) wrote:
Hi Joel,
Thanks for your reply and comment.
The bullet list in section 4 was introduced before the TEAS NS design team,
that is only a problem if one needs different options aimed at different
service functions. Even NSH does not actually do that.
So define a destination option to carry service parameters. Put it in a
destination option before the CRH. then every addressed entity examines
it. It is marked as
Aijun, I am not sure I properly understand your request.
In some qys, it sounds like what you are asking for is conventional MPLS.
In other ways, it sounds like you are asking for Ross Callon's old
writeup on adjusting routing metrics to achieve traffic engineering.
Are those objections to
Part of my concern is that the document claims that this technique is
necessary to use resource reservation with segment routing. Given that
we know there are existing ways people do use resource reservation with
SR, it is not necessary.
The term "isolation" has been extensively debated in
Given that the requirement to be able to ignore the routing header
predates any of the SRv6 work, a natural reading would be that ignoring
the header is something the device can already do. In normal
situations, the savings for not doing a check that simple is very small.
Having been told
A case with no SRH is clearly not a case for PSP.
With regard to the case for PSP, as I said in my note I am concerned
that if we want to support this specific case, then there are
restrictions on deployment and operation that need to be called out.
For example, a path compute engine for
arified in the text as well as on the
mailer.
So I fail to understand the resistance of “the other side (including
yourself)”.
Therefore, I would suggest we go ahead with the declared Spring WG
consensus.
Thanks,
Ketan
[1]
https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-st
atus-05#s
Bruno's statement, which you chose to quote, was that all it takes is
for one person to find something useful. I was responding to what the
chair said. It is not true as stated.
Having said that, I agree that more than one person has asked for this.
But the actual requirement is that there
While the node is "asserting" that the two are the same, if you use
different SIDs for OAM compared with data traffic then you are not
actually checking the same forwarding path. You are not using the same
FIB entries. Sure, if everything works right they are the same. But
the whole point
Zafar, thank you for taking steps to address my concerns. There seem to
be several issues remaining. I am not sure I spotted them all, as the
ones I see may be masking other issues.
[Side note to the chairs: I have no idea how to enter a general
discussion of this sort as a pull request.
I would like to see working path MTU of some form for many different
reasons.
I would also like to see larger practical MTUs.
However, history suggests that both goals may be more aspirational than
practical.
I tend to be very skeptical of any anlysis that says that user traffic
is changing
Thank you. I apologize for missing the other normative items. With
those, plus the elaboration on the SRMS, the status as PS makes good sense.
Yours,
Joel
On 5/21/18 11:45 AM, Ahmed Bashandy wrote:
Thanks a lot for the review
The document specifies externally visible behavior that must be
cking.
I leave it to the draft authors to resolve this issue with you.
Les
-----Original Message-
From: Joel Halpern Direct <jmh.dir...@joelhalpern.com>
Sent: Monday, May 14, 2018 1:16 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Joel Halpern
<j...@joelhalpern.com>
Thanks Les. I wondered if that were the case.
Looking again at the draft, the problem then is that section 4.2 of the
subject draft is not a normative definition of an SRMS. It states the
general functionality, and then provides an example of how it would work
in the given scenario.
If
17 matches
Mail list logo
