I have reviewed the latest update to this draft.
Unfortunately, the new revision does not address the comments/concerns
expressed both at IETF 120 and on the mailing list.
I do not know if the concerns of some WG members were not made clear to the
authors - or if the authors intentionally c
Hi, Tony:
I would like to remind you for your offensive descriptions of the ongoing
discussions.
Let's focus on the technical arguments.
I have raised the example at
https://mailarchive.ietf.org/arch/msg/lsr/vLgK5PrTPZUAyZ-x7NSSddWqBzU/,
describes that to implement the slice/glue of the big IS-IS
Can't we just call the question?
On Wednesday, October 23, 2024 at 10:38:19 AM PDT, Acee Lindem
wrote:
The reason for rehashing is that the chairs had declined off list the request
to present the updated draft at IETF 121. Subsequently, the author took the
matter to the mailing list.
The reason for rehashing is that the chairs had declined off list the request
to present the updated draft at IETF 121. Subsequently, the author took the
matter to the mailing list.
Better to have an open discussion in the interest of maximizing the F2F time in
the LSR session.
Thanks,
Acee
FYI - This report has been deleted as junk.
Thank you,
RFC Editor/mc
> On Oct 17, 2024, at 10:21 PM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC,
> "Management Information Base for Intermediate System to Intermediate System
> (IS-IS)".
>
> --
+1
And to the extent that my well intentioned but clearly less than successful
posts contributed to the noise, I apologize.
The chairs have my full support.
Les
> -Original Message-
> From: Tony Li On Behalf Of Tony Li
> Sent: Wednesday, October 23, 2024 7:51 AM
> To: Hannes Gredle
Amen
Sent from my iPhone
> On Oct 23, 2024, at 10:52 AM, Tony Li wrote:
>
>
>
>> Why are we having this discussion again ?
>
>
> Because we have one member who refuses to respect the rough consensus of the
> working group. I will not speculate on motivations, but none of the
> possibilit
> Why are we having this discussion again ?
Because we have one member who refuses to respect the rough consensus of the
working group. I will not speculate on motivations, but none of the
possibilities are good.
This places the chairs in the difficult position of having to deal with a DoS
Les,
A very cogent and graceful explanation.
John
On Tuesday, October 22, 2024 at 10:23:50 PM PDT, Les Ginsberg (ginsberg)
wrote:
Sfor the benefit of the WG...
Aijun has sent many messages making the same claims. In the past I (and others)
have made attempts to explai
Hi Hannes,
How do you deal with MTU of the links if your TLV can grow to 65K octets ?
The workarounds to use multiple system IDs or more LSPs seem far from
perfect.
Related to the subject - IMO we should aim to shrink not grow in size ISIS
LSPs. MP seems to be doing the right thing here in provid
Why are we having this discussion again ?
My recollection is that we have a “good enough” solution that is deployed and
interoperable.
If you want the “generic solution” then the 16-bit TLVs described in RFC7356 is
the way to go forward and if there is concern about incremental deployment then
Hi, Les:
“an implementation to correctly/reliably differentiate the objects described in
two different TLVs of the same type” doesn’t represent it CAN concatenate the
sliced IS-IS TLVs together, the necessary function of any sliced proposal
requires.
For example, for TLV type 22(“Extend
12 matches
Mail list logo
