My 2c: please take it offline.
Thank you,
-ed
On Fri, Nov 1, 2024, 7:02 PM Aijun Wang wrote:
> Hi, Chris:
>
> Until now, I haven’t heard you, and also other experts for the technical
> analysis of UPDATED big-TLV solution(
> https://datatracker.ietf.org/doc/draft-wang-lsr-isis-big-tlv/)
>
> L
Hi, Chris:
Until now, I haven’t heard you, and also other experts for the technical
analysis of UPDATED big-TLV
solution(https://datatracker.ietf.org/doc/draft-wang-lsr-isis-big-tlv/)
Lack of such technical analysis, any subjective conclusion is untenable.
It’s same as declaring again and agai
Hi, Les:From its publication on September 2014, RFC 7356 has been existing 10 years, can you give some examples that which vendor has implemented it, which operator has deployed it?Don’t you think RFC7356 is one failure RFC? Why encourage other persons to solve the problem based on such RFC?MP-TLV
And given that there are multiple LSPs per node, the IS-IS MTU limit is only
for a single top-level TLV. Should this become a problem, we already have some
experience with TLV/sub-TLV concatenation 😉
> On Nov 1, 2024, at 12:12 PM, Les Ginsberg (ginsberg)
> wrote:
>
> Robert –
> Your comments
Les,
> But that argument doesn’t apply here.
It does. How UPA or TE link delays are needed on any other node then TE
headends ?
> Your comments are many years late. 😊
Well they are not late .. but got successfully ignored. And I am not
saying block new innovation and close the shop. But I am q
Precisely Sent from my iPhoneOn Nov 1, 2024, at 12:13 PM, Les Ginsberg (ginsberg) wrote:
Robert –
Your comments are many years late.
😊
Things like TE, Segment Routing, flex-algo were incorporated into the protocol years ago.
Critiquing the transport because it is being extended to mee
Robert –
Your comments are many years late. 😊
Things like TE, Segment Routing, flex-algo were incorporated into the protocol
years ago.
Critiquing the transport because it is being extended to meet the requirement
of functionalities that have been standardized is not sensible.
If you want to ar
> It is required because we have a need for more than 255 bytes of data
directly used by the protocol.
Seems pretty clear that we have differences of opinion in classification of
stuff which went into the protocol in the recent decade to be really needed
by routing or perhaps used by various optio
Robert –
The need for more than 255 bytes/TLV in this case has nothing to do with
“non-routing-protocol-data”. It is required because we have a need for more
than 255 bytes of data directly used by the protocol.
Please do not conflate this with issues related to requests for the IGPs to
carry
Hello Donald,
TL;DR
The point I wanted to make is just that the Big Container TLV serves no
practical purpose.
henk.
My answer to Donald, not relevant to the topic of Container TLVS:
===
> I assume you mean 16-bit Length, not Value. ... RFC 7356.
No, I actually meant 16 bits for both Type and
Thx Les !
I asked this 2nd time as IMO direction towards growing TLV sizes is not the
best solution.
Especially for opaque to routing information which applies to (tiny) subset
of link state nodes in the IGP domain.
See if you keep bringing larger and larger trucks folks will happily keep
loadin
11 matches
Mail list logo
