Hi Yingzhen,
With the help of the secretary of RTGDIR, the review status has been updated.
Best regards,
Mach
From: Yingzhen Qu
Sent: Thursday, February 13, 2025 2:44 AM
To: Mach Chen
Cc: Les Ginsberg (ginsberg) ; Christian Hopps
; rtg-...@ietf.org; rtg-...@ietf.org;
draft-ietf-lsr-multi-tlv
Hi Mach,
Thanks for confirming that your concern has been addressed. Would you
please update the RTGDIR review status?
Thanks,
Yingzhen
On Tue, Feb 11, 2025 at 11:57 PM Mach Chen wrote:
> Hi Les,
>
> Thanks for the reminder!
>
> I reviewed the latest version and noticed that the following text
Thank you Mach.
Les
> -Original Message-
> From: Mach Chen
> Sent: Tuesday, February 11, 2025 11:57 PM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
>
> Cc: rtg-...@ietf.org; rtg-...@ietf.org;
> draft-ietf-lsr-multi-tlv@ietf.org; Lsr
> ; last-c...@ietf.org
> Subject: RE: RtgDi
Hi Les,
Thanks for the reminder!
I reviewed the latest version and noticed that the following text from V6 has
been removed, which addressed my major concern.
"If a Multi-part TLV contains information that specifies the applicability of
its contents (i.e., a key), the key information MUST be
Mach -
We have now resumed work on the draft - V7 has been posted.
Please take a look.
Thanx very much.
Les
> -Original Message-
> From: Mach Chen
> Sent: Thursday, November 14, 2024 1:35 AM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
>
> Cc: rtg-...@ietf.org; rtg-...@ietf.org;
Hi Les,
Thanks for the detailed explanation, looking forward to seeing the update.
Thanks,
Mach
> -Original Message-
> From: Les Ginsberg (ginsberg)
> Sent: Wednesday, November 13, 2024 2:37 AM
> To: Mach Chen ; Christian Hopps
>
> Cc: rtg-...@ietf.org; rtg-...@ietf.org;
> draft-ietf-
Mach -
As regards this quote:
""If a Multi-part TLV contains information that specifies the
>applicability of its contents (i.e., a key), the key information MUST
>be replicated in additional TLV instances so that all contents
>specific to that key can be identified."
Some context ne
Hi Les,
Some replies inline...
> -Original Message-
> From: Les Ginsberg (ginsberg)
> Sent: Tuesday, November 12, 2024 4:09 PM
> To: Mach Chen ; Christian Hopps
>
> Cc: rtg-...@ietf.org; rtg-...@ietf.org;
> draft-ietf-lsr-multi-tlv@ietf.org; Lsr
> ; last-c...@ietf.org
> Subject: RE
Mach -
> I hadn’t closely followed this topic’s discussion before, but after taking on
> this
> review task, I read most of the related emails. I remain unconvinced by the
> idea that we should ‘rely on experienced ISIS implementers to understand the
> composition of each MP-TLV Key.’ While this
Mach -
Apologies. My mailer sometimes truncates inline replies.
Let me try again - top posting.
We do NOT introduce the "concept of a key".
We introduce the use of a generic term ("key") to refer to those codepoint
specific elements which uniquely identify the objects being advertised.
We also d
Hi Chris,
Please see my reply inline...
> -Original Message-
> From: Christian Hopps
> Sent: Monday, November 11, 2024 8:14 PM
> To: Mach Chen
> Cc: rtg-...@ietf.org; rtg-...@ietf.org;
> draft-ietf-lsr-multi-tlv@ietf.org; Lsr
> ; last-c...@ietf.org
> Subject: Re: RtgDir Last Call R
Aijun Wang writes:
Hi, Robert:
Fragments and Glue procedures is one normal, mature process for any
slicing application. We needn’t another document to standardize it
again.
The knob for the segmentation is the information “what concerns a
key”, which is what you mentioned should be in one w
@ietf.org<mailto:draft-ietf-lsr-multi-tlv@ietf.org>;lsrmailto:lsr@ietf.org>>;last-callmailto:last-c...@ietf.org>>
主题： [Lsr] Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
时间： 2024-11-12 08:06:09
Yawn
Sent from my iPhone
On Nov 11, 2024, at 6:48 PM, Aijun Wang wrot
Hi, Robert:Fragments and Glue procedures is one normal, mature process for any slicing application. We needn’t another document to standardize it again.The knob for the segmentation is the information “what concerns a key”, which is what you mentioned should be in one wiki like online form.If the
YawnSent from my iPhoneOn Nov 11, 2024, at 6:48 PM, Aijun Wang wrote:Hi, Robert and Mach:Thanks for your comments on this document.It reveals clearly the issues existing within the documents.The Chairs declare repeatedly this document reached WG consensus, apparently it DOESN’T.I have submitted t
Hi Aijun,
Let's make sure that my observation in respect to key elements
clarification for each TLV does not equal to the request to "ABANDON" this
useful document.
I do find the ability to fragment and glue TLVs as a useful protocol
extension. What should be sent in each fragment perhaps is obvi
Hi, Robert and Mach:Thanks for your comments on this document.It reveals clearly the issues existing within the documents.The Chairs declare repeatedly this document reached WG consensus, apparently it DOESN’T.I have submitted the appeal to IESG.Wish more experts to stand out to ABANDON this error
Les,
> Link identifiers are indeed sub-TLVs.
> That does not disqualify them from being part of “key” information.
Oh, it was not clear from the draft. Perhaps you can add this detail in the
next rev.
- - -
If you have multiple parallel links today they will all be listed in the
sub-TLVs - so
Robert –
Link identifiers are indeed sub-TLVs.
That does not disqualify them from being part of “key” information.
If I have multiple parallel links between two routers, this is how the links
are uniquely identified. Such information is essential to correctly identify
the link attribute informa
Les,
I note that in all of these emails expressing concern no one has provided a
> single example
>
RFC5305 defines Extended IS Reachability TLV as:
The proposed extended IS reachability TLV contains a new data
structure, consisting of:
7 octets of system ID and pseudonode number
Acee –
(I assume you meant “should NOT be a gating factor…”)
I would NOT welcome such a document.
Writing redundant specifications adds nothing of value and risks ambiguity.
If existing specifications are unclear let’s fix them.
I note that in all of these emails expressing concern no one has pr
Speaking as WG member:
> On Nov 11, 2024, at 15:21, Robert Raszuk wrote:
>
> Dear Christian,
>
> Thank you for your answer. I remain educated that LSR WG born RFCs are only
> for those who implement protocol and have years of experience in doing so.
>
> I was obviously wrong thinking RFCs ar
This is all blindling obvious to the informed reader.Sent from my iPhoneOn Nov 11, 2024, at 3:49 PM, Les Ginsberg (ginsberg) wrote:
Robert –
RFCs are documents defining normative behavior.
They are not troubleshooting guides.
As for the rest of your comments, please see
https://mailar
Robert –
RFCs are documents defining normative behavior.
They are not troubleshooting guides.
As for the rest of your comments, please see
https://mailarchive.ietf.org/arch/msg/lsr/eB4RLebv07i6yipRLuorF_azkbU/
Les
From: Robert Raszuk
Sent: Monday, November 11, 2024 12:22 PM
To: Christian Ho
Dear Christian,
Thank you for your answer. I remain educated that LSR WG born RFCs are only
for those who implement protocol and have years of experience in doing so.
I was obviously wrong thinking RFCs are designed to also help operators to
run and troubleshoot network problems. Or maybe say wir
As was pointed out on the list, anyone implementing IS-IS knows exactly what a
key is b/c it’s literally the value they use to differentiate TLVs from one
another — IOW *A KEY VALUE*. You don’t consider 2 neighbor TLVs to be different
neighbors (and allocate a neighbor structure to store in your
Hi Chris,
> The WG explicitly decided it was inappropriate to have this document
re-define
> every "key" for every possible TLV as these "key" values are already
defined
> by the documents that define the TLV;
I have followed this discussion on the list.
It seems to be as a side observer that fo
Mach Chen writes:
Hello，
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is t
28 matches
Mail list logo
