Andrew,
I would like to amplify something that you said. SRv6 and SRv6+ are both
designed to operate within limited domains. Beyond competing for market share,
the existence of one does not threaten the existence of the other.
I do not oppose the progressing of the SRv6 drafts (while, as a WG
You are technically correct that the SR Architecture document does not
require the separation of topological behavior from service behavior.
On the other hand, MANY of us have notied, and tried to find solutions
for, the fact that the overloading of IP addresses for both identity and
location
Hi Andrew,
> There is a phrase that I have heard – and perhaps it applies here – perhaps
> we need to put our guns down – and find a way to in which we can move forward
> that while it probably will not satisfy everyone, will be in the interests of
> the market in general by avoiding a total
Hi Andrew,
> And yes, as was alluded to, I did raise the possibility of an inter-op
draft to facilitate
> forward movement here, and I had only one vendor out of all the vendors I
approached
> actually indicate opposition to this, so I would ask now directly on
list, can we work
> towards a
Ok, so couple of things.
I really think we need to clearly and totally divorce the comments on this list
from those around SRH – since – there seems to be this kind of bizarre
conflating of two issues, and while it’s a nice piece of obfuscation – let’s be
clear on a number of things.
1.
>
> On Wed, 11 Sep 2019, 14:21 Satoru Matsushima,
> wrote:
>>>
On Wed, 11 Sep 2019, 13:46 Satoru Matsushima,
wrote:
Hi Aijun,
>
>
> But the concept of SRv6+ is more clear than the SRv6(topology/service
> instruction separation;
>
The
On Wed, 11 Sep 2019, 14:21 Satoru Matsushima,
wrote:
>
> On Wed, 11 Sep 2019, 13:46 Satoru Matsushima,
> wrote:
>
>> Hi Aijun,
>>
>>
>>
>> But the concept of SRv6+ is more clear than the SRv6(topology/service
>> instruction separation;
>>
>>
>> The SR architecture never require such things. See
Hi, Robert:
But the concept of SRv6+ is more clear than the SRv6(topology/service
instruction separation; different instruction carried in different IPv6 EH).
Hi Aijun,
Can you please various thread to gauge the complexity, incompleteness and why
CRH (aka SRv6+) makes no sense, e.g.,:
*
>
>> On Wed, 11 Sep 2019, 13:46 Satoru Matsushima,
>> wrote:
>> Hi Aijun,
>>
>>>
>>>
>>> But the concept of SRv6+ is more clear than the SRv6(topology/service
>>> instruction separation;
>>>
>>
>> The SR architecture never require such things. See RFC8402:
>>
>> “Abstract
>>
>> Segment
On Wed, 11 Sep 2019, 13:46 Satoru Matsushima,
wrote:
> Hi Aijun,
>
>
>
> But the concept of SRv6+ is more clear than the SRv6(topology/service
> instruction separation;
>
>
> The SR architecture never require such things. See RFC8402:
>
> “Abstract
>
>
>Segment Routing (SR) leverages the
Hi Aijun,
>
> But the concept of SRv6+ is more clear than the SRv6(topology/service
> instruction separation;
The SR architecture never require such things. See RFC8402:
“Abstract
Segment Routing (SR) leverages the source routing paradigm. A node steers a
packet through an ordered list of
Hi, Robert:
But the concept of SRv6+ is more clear than the SRv6(topology/service
instruction separation; different instruction carried in different IPv6 EH).
It conforms to RFC8200 as well, seems will be less resisted within 6man WG.
Will such enhancements accelerate the deployment of SR
12 matches
Mail list logo
