Hi Peng, your question is part of why I asked for some descriptions of how an
SR Source chooses a SID of one of these behaviors vs another. I think we’ll
know more once we see that.
Darren
On 2021-11-08, 10:32 PM, "spring" wrote:
Hi authors,
Thanks for bringing SRv6 SID swaping idea in the
Let me try phrasing the question about the SRH TLV in a different way.
And this is as a participant, not as co-chair.
Assumptions as I understand them:
1) The 6man draft requires support of both the HbH and DoH cases
2) Any node supporting the SRH altMarking can be assumed to also support
the 6m
Assumption 2 is not correct. We assume there are nodes support srh but not hbh
and doh.
Best,
Tianran
Sent from WeLink
发件人： Joel M. Halpernmailto:j...@joelhalpern.com>>
收件人： Giuseppe
Fioccolamailto:giuseppe.fiocc...@huawei.com>>
抄送：
draft-fz-spring-srv6-alt-m
On Tue, Nov 9, 2021 at 7:31 AM Joel M. Halpern wrote:
>
> Let me try phrasing the question about the SRH TLV in a different way.
> And this is as a participant, not as co-chair.
> Assumptions as I understand them:
>
> 1) The 6man draft requires support of both the HbH and DoH cases
> 2) Any node s
Hi Tianran,
such a combination seems very strange to me. A vendor decides to
support the AltMarking in SRv6 (SRH TLV) but not in IPv6? Possible but,
IMHO, unlikely decision.
Regards,
Greg
On Tue, Nov 9, 2021 at 7:39 AM Tianran Zhou wrote:
>
> Assumption 2 is not correct. We assume there are nod
I am not saying alt mk, but generic case. I know major chip vendors can support
srh but not support hbh nor doh.
That’s why hbh packets easily to be dropped. This is consensus in my opinion.
Sent from WeLink
发件人： Greg Mirskymailto:gregimir...@gmail.com>>
收件人： T
Hi Peng,
The choice to advertise REPLACE or REPLACEB6 is not based on the sid-list on
which it is resolving.
We will update the draft with details and examples for all the SIDs to clarify.
You can review the updated draft and we can discuss if you have further
questions.
Rgds
Shraddha
Junipe
Hi Tom,
All you arguments are correct.
If a network is built all by supportive devices (support HbH, DoH), there is no
doubt that 6man-alt-mk is a sound solution.
However, existing network may consist many non-supportive devices. These
devices may
1. support SRH, but not HbH and DoH. This is t
(Again, speaking as participant.)
You seem to be assuming that devices (hard or soft) that support SRH
will support this new TLV. It is not obvious that they will support any
SRH TLVs. And if they do, they clearly will not support a not yet
defined TLV.
Yours,
Joel
On 11/9/2021 9:04 PM, T
On Tue, Nov 9, 2021 at 6:39 PM Joel M. Halpern wrote:
>
> (Again, speaking as participant.)
> You seem to be assuming that devices (hard or soft) that support SRH
> will support this new TLV. It is not obvious that they will support any
> SRH TLVs. And if they do, they clearly will not support
Hi Joel,
I do not need to assume a device that support SRH will support this new TLV.
We only assume the device that do not support this new TLV can ignore and
bypass the packet, not to drop.
I see text from RFC8754 section 2.1.
" all TLVs are ignored unless local configuration indicates otherwis
11 matches
Mail list logo
