Zahed, Bruno, and Les,
Thanks for bringing this issue to completion.
Acee
> On May 2, 2024, at 8:46 AM, bruno.decra...@orange.com wrote:
>
> Hi Zahed,
> Top posting as I believe Les and you came to a conclusion.
> The below thread will be reflected in -10.
> In short, for the second
Speaking as WG member:
I support adoption. An overly restrictive allocation policy prevents us from
pursuing experimental IS-IS protocol extensions and this draft corrects that.
Thanks,
Acee
> On May 2, 2024, at 10:35 AM, Yingzhen Qu wrote:
>
> Hi,
>
> This email begins a 2 week WG
I support WG adoption.
Peter
On 02/05/2024 16:35, Yingzhen Qu wrote:
Hi,
This email begins a 2 week WG adoption poll for the following
draft:https://datatracker.ietf.org/doc/draft-li-lsr-labv-registration/
Please review the document and indicate your support or objections by
May 16th, 2024.
I support WG adoption.
The change will allow all classes of IETF documents to obtain codepoints from
IS-IS related registries and will make the registration mechanism consistent
for all IS-IS related registries – both of which are desirable changes.
Les
From: Lsr On Behalf Of Yingzhen Qu
As author, I support adoption.
I am unaware of any undisclosed IPR.
Tony
> On May 2, 2024, at 7:35 AM, Yingzhen Qu wrote:
>
> Hi,
>
> This email begins a 2 week WG adoption poll for the following draft:
> https://datatracker.ietf.org/doc/draft-li-lsr-labv-registration/
>
> Please review
Hi,
This email begins a 2 week WG adoption poll for the following draft:
https://datatracker.ietf.org/doc/draft-li-lsr-labv-registration/
Please review the document and indicate your support or objections by
May 16th, 2024.
Although there is no IPR expected related to this draft. For the
Hi Tony and Les,
Thanks for the reminder and challenge. To get the whole process done in
three months is really challenging, especially considering we can't control
everything.
But first thing first, I'll start the adoption call.
Thanks,
Yingzhen
On Wed, May 1, 2024 at 10:22 AM Tony Li wrote:
Hi Zahed,
Thanks for the discussion. I believe we are converging.
Please see inline [Bruno3]
-10 has been published and should cover those changes.
Given that the three parallel emails threads are becoming a bit long, once you
have reviewed -10 and if you identify further/continuing issues, may
Thank you John, Les, Zahed for helping.
In -10 we have added text in the introduction to better introduce the changes
brough by this document.
In short, with the following two additions spread in the Intro
"IS-IS base specification does not use flow or
congestion control but static flooding
Hi Zahed,
Top posting as I believe Les and you came to a conclusion.
The below thread will be reflected in -10.
In short, for the second approach:
*:s/SHOULD/should
* “Flow control is not used by this approach.”
--Bruno
Orange Restricted
From: Lsr On Behalf Of Les Ginsberg
Hi all,
-10 is intended to address Zahed's comments.
I'll reply to each emails/threads to detail the changes.
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-10
--Bruno, on behalf of the authors
Orange Restricted
Internet-Draft draft-ietf-lsr-isis-fast-flooding-10.txt is now available. It
is a work item of the Link State Routing (LSR) WG of the IETF.
Title: IS-IS Fast Flooding
Authors: Bruno Decraene
Les Ginsberg
Tony Li
Guillaume Solignac
Marek
12 matches
Mail list logo
