[Last-Call] Re: [Lsr] Re: 答复: Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I think this an excellent point.  The draft is simply documenting what has already been deployed in existing IS-IS networks.  So, arguments that there are issues with it are completely specious.

Sent from my iPhone

> On Nov 12, 2024, at 6:43 AM, Christian Hopps <chopps@xxxxxxxxxx> wrote:
> 
> Hi Robert,
> 
> I think perhaps this document is actually presenting something too obvious (multiple vendors have already implemented the functionality w/o any document existing), and so it's causing people to think there is more going on than there is. I believe you can summarize the entire thing this way:
> 
> "Instead of replacing TLV data (legacy) you concatenate (multi-part)."
> 
> Nothing else is being defined here -- it's that simple -- although obviously saying that with normative language has been way harder.
> 
> Thanks,
> Chris.
> [as wg-member]
> 
> Christian Hopps <chopps@xxxxxxxxxx> writes:
> 
>> [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps <chopps@xxxxxxxxx> (trust ultimate) created at 2024-11-12T06:26:47-0500 using RSA]]
>> 
>> Robert Raszuk <robert@xxxxxxxxxx> writes:
>> 
>>> Hi Chris,
>>> 
>>> You are 100% correct that today all specifications already define a
>>> set of values which are necessary to recognize TLVs to be coming from
>>> the same originator (originator can be a node_id or node_id+link_id
>>> etc ...). 
>>> 
>>> What seems to be the crux of the matter here is that MP-TLV spec
>>> recommends with normative MUST that a *subset* of those values (aka
>>> "keys") should be used when fragmenting TLV into chunks and attach to
>>> each one of them. It is this lack of definition on what is that
>>> *subset* which seems to be missing here. 
>>> 
>>> Intuitively, and I think this is highlighted in your and Les's
>>> responses that *subset* is what makes the TLV unique ... so values
>>> like metric, down/up bits etc ... would not be part of such
>>> *subsets*. The issue is that this is nowhere defined. 
>> 
>> It's more than intuitive. This key value subset has to be exactly understood or
>> the protocol would not function, you would either be replacing one neighbor with
>> another niehgbor's TLV data (subset too small) or you would be creating multiple
>> fake neighbors for a single actual neighbor (subset too large). The subset has
>> to be exactly understood already or the TLV database would be corrupt on
>> existing IS-IS.
>> 
>> This is why Les mentioned if the data is not actually well-defined in the
>> original RFC then we need to fix that RFC b/c IS-IS operation could be corrupted
>> even when no multi-part TLVs were in use. No example of this has been presented
>> yet though..
>> 
>> Thanks,
>> Chris.
>> 
>> 
>>> 
>>> So perhaps instead of asking to create a live document where such
>>> subsets are explicitly enumerated for each TLV (which still may be
>>> useful and can be done in no time as each IETF WG already have a wiki
>>> page) - for this current topic maybe just define in the MP-TLV doc
>>> this *subset* as unique set of elements used for identification and
>>> we will be done. (Even if for folks working on ISIS for decades this
>>> is soooo obvious :). 
>>> 
>>> Thx,
>>> Robert
>>> 
>>> On Tue, Nov 12, 2024 at 10:29 AM Christian Hopps <chopps@xxxxxxxxxx>
>>> wrote:
>>> 
>>> 
>>>    Aijun,
>>> 
>>>    Key values are defined in existing RFCs, the actual use of the
>>>    word "KEY" is not necessary to understand what the key data is.
>>>    Sadly, this has had to be repeated over and over and over in this
>>>    discussion to no affect.
>>> 
>>>    While reading the following text, please just consider regular
>>>    IS-IS (i.e., the set of existing standards)
>>> 
>>>    If the key data wasn't already defined in the existing RFCs then
>>>    each router would store exactly 0 or 1 of each TLV code point.
>>>    You would have 0 or 1 neighbor TLV, you would have 0 or 1 IP
>>>    reachable prefix, etc.
>>> 
>>>    And IS-IS would be utterly broken as a protocol.
>>> 
>>>    So then ask yourself, how does IS-IS tell these TLVs apart? How
>>>    do we support more than 1 neighbor already? Because we have *key*
>>>    data in each TLV to identify each neighbor as different from the
>>>    other!
>>> 
>>>    If the key data wasn't already defined and understood you
>>>    literally couldn't have more than 1 of each of these TLVs in
>>>    exiting IS-IS.
>>> 
>>>    [rhetorical] Do you believe that IS-IS currently only supports 1
>>>    neighbor, only 1 IPv4 prefix, only 1 IPv6 prefix?
>>> 
>>>    Nothing new is being introduced, no new "key"s are being defined,
>>>    no new "keys" need to be defined. There can be no confusion on
>>>    what the key data is or IS-IS would not work at all.
>>> 
>>>    Thanks,
>>>    Chris.
>>>    [as wg-member]
>>> 
>>> 
>>>    "Aijun Wang" <wangaijun@xxxxxxxxxxxxxxx> writes:
>>> 
>>>    > Hi, Chris:
>>>    >
>>>    > I recommended you read carefully the arguments from Robert
>>>    https://mailarchive.ietf.org/arch/msg/lsr/
>>>    g6r1zwMfcmOPUoKMNYOMidvyqeA/
>>>    >
>>>    > And also to Les's statement: " But defining encodings that are
>>>    already fully specified in existing RFCs is not in
>>>    scope."--------we are arguing where in existing RFC gives the
>>>    information "what constitute a key"?
>>>    > WHERE?  We can limit only to TLV 22 and TLV135, as the examples
>>>    in your document.
>>>    >
>>>    >
>>>    > For your conveniences, I copied the original part(there is no
>>>    any change) as the below:
>>>    >
>>>    > ============================Quote Start(Mail from Robert, Nov.
>>>    11, 2024)========================================================
>>>    =
>>>    > 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
>>>    >       3 octets of default metric
>>>    >       1 octet of length of sub-TLVs
>>>    >
>>>    > Now your draft makes an impression that there are also at the
>>>    TLV level
>>>    > itself optional link identifiers.
>>>    >
>>>    > 4.1.  Example: Extended IS Reachability
>>>    >
>>>    >    As an example, consider the Extended IS Reachability TLV
>>>    (type 22).
>>>    >    A neighbor in this TLV is specified by:
>>>    >
>>>    >    *  7 octets of system ID and pseudonode number
>>>    >
>>>    >    *  3 octets of default metric
>>>    >
>>>    >    *  Optionally one or more of the following link identifiers:
>>>    >
>>>    >       -  IPv4 interface address and IPv4 neighbor address as
>>>    specified
>>>    >          in [RFC5305]
>>>    >
>>>    >       -  IPv6 interface address and IPv6 neighbor address as
>>>    specified
>>>    >          in [RFC6119]
>>>    >
>>>    >       -  Link Local/Remote Identifiers as specified in
>>>    [RFC5307]
>>>    >
>>>    >
>>>    > Can you point to the text in RFC5305 where such IPv4 link
>>>    identifier is
>>>    > defined ?
>>>    >
>>>    > I can only find them to be defined as part of sub-TLVs.
>>>    >
>>>    > Also I do not see them as LSDB keys in FRR ISIS code ...
>>>    > Ref: https://github.com/FRRouting/frr/blob/master/isisd/isisd.c
>>>    >
>>>    > Thx,
>>>    > R.
>>>    > ========================= Quote End(Mail from Robert, Nov. 11,
>>>    2024)============================================================
>>>    =
>>>    >
>>>    >
>>>    >
>>>    >
>>>    > -----邮件原件-----
>>>    > 发件人: forwardingalgorithm@xxxxxxxx [mailto:
>>>    forwardingalgorithm@xxxxxxxx] 代表 Christian Hopps
>>>    > 发送时间: 2024年11月12日 14:08
>>>    > 收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx>
>>>    > 抄送: Robert Raszuk <robert@xxxxxxxxxx>; Les Ginsberg
>>>    (ginsberg) <ginsberg@xxxxxxxxx>; Acee Lindem <acee.ietf@xxxxxxxxx
>>>    >; Christian Hopps <chopps@xxxxxxxxxx>; Mach Chen <mach.chen=
>>>    40huawei.com@xxxxxxxxxxxxxx>; Routing ADs <rtg-ads@xxxxxxxx>;
>>>    rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr <
>>>    lsr@xxxxxxxx>; last-call <last-call@xxxxxxxx>
>>>    > 主题: [Lsr] Re: RtgDir Last Call Review:
>>>    draft-ietf-lsr-multi-tlv-06
>>>    >
>>>    >
>>>    > Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> 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 wiki like
>>>    online
>>>    >> form.
>>>    >>
>>>    >> If the LSR WG can formalize such “online form”, and this
>>>    document
>>>    >> refer to it for the future implementation and interoperability
>>>    >> guarantee, then I can support its forwarding.
>>>    >>
>>>    >> BUT, it seems impossible to define explicitly such “online
>>>    form”.
>>>    >>
>>>    >> And to Chris: if you think “what constitutes a key” is one
>>>    well-known
>>>    >> knob for vendors, why the document illustrate explicitly such
>>>    >> information for TLV 22 and TLV 135?
>>>    >>
>>>    >> And how can you assure different vendors will use the same
>>>    information
>>>    >> for “what constitutes a key” for each IS-IS code point?
>>>    >
>>>    > Aijun,
>>>    >
>>>    > You have asked this many times and been answered repeatedly;
>>>    however, I will answer it again, if only to make it clear to the
>>>    folks reviewing the appeal.
>>>    >
>>>    > Please stop thinking about Multi-TLV for a minute.
>>>    >
>>>    > How does IS-IS tell one neighbor TLV (or whatever) from another
>>>    -- in regular deployed IS-IS?
>>>    >
>>>    > That is the "key" data.
>>>    >
>>>    > The "key" data *has* to already be agreed upon by all
>>>    implementations or regular IS-IS would not function -- it would
>>>    literally not function. There is nothing new to define.
>>>    >
>>>    > Thanks,
>>>    > Chris.
>>>    >
>>>    >>
>>>    >> It’s better to answer such question clearly, reasonably than
>>>    to
>>>    >> declare in rush that document reaches the WG consensus.
>>>    >>
>>>    >>
>>>    >> Aijun Wang
>>>    >> China Telecom
>>>    >>
>>>    >>
>>>    >>     On Nov 12, 2024, at 08:00, Robert Raszuk <
>>>    robert@xxxxxxxxxx>
>>>    >>     wrote:
>>>    >>
>>>    >>
>>>    >>     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 obvious to familgia of long time ISIS developers .. so
>>>    my only
>>>    >>     hint was to simply publish this in some online form.
>>>    >>
>>>    >>     Rgs,
>>>    >>     Robert
>>>    >>
>>>    >>
>>>    >>     On Tue, Nov 12, 2024 at 12:45 AM Aijun Wang <
>>>    >>     wangaijun@xxxxxxxxxxxxxxx> 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 the appeal to IESG.
>>>    >>         Wish more experts to stand out to ABANDON this error
>>>    prone,
>>>    >>         pitfall solution being published under the name of
>>>    LSR, or
>>>    >>         IETF.
>>>    >>
>>>    >>         Aijun Wang
>>>    >>         China Telecom
>>>    >>
>>>    >>
>>>    >>             On Nov 12, 2024, at 06:55, Robert Raszuk <
>>>    >>             robert@xxxxxxxxxx> wrote:
>>>    >>
>>>    >>
>>>    >>             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 they are ok spec
>>>    wise
>>>    >>             today.
>>>    >>
>>>    >>             I am not sure however - assuming you do not
>>>    include
>>>    >>             "Example" in section 4.1 that everyone would be
>>>    adding
>>>    >>             them to each TLV fragment.
>>>    >>
>>>    >>             // But then we have hackathons and interop venus
>>>    where
>>>    >>             interop bugs can be quickly found and fixed
>>>    >>             // if this is how it should all work out.
>>>    >>
>>>    >>             That is why I do believe a sort of dictionary
>>>    would be
>>>    >>             nice to have in either a normative spec or
>>>    reference to
>>>    >>             such a document or even as a simple wiki page :).
>>>    >>
>>>    >>             Best,
>>>    >>             Robert
>>>    >>
>>>    >>
>>>    >>             On Mon, Nov 11, 2024 at 11:39 PM Les Ginsberg
>>>    (ginsberg)
>>>    >>             <ginsberg@xxxxxxxxx> wrote:
>>>    >>
>>>    >>
>>>    >>                 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
>>>    information
>>>    >>                 which in turn is essential for applications
>>>    such as
>>>    >>                 RSVP-TE, SR=TE, and flex-algo to operate
>>>    correctly.
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 If you think this is underspecified, I presume
>>>    you
>>>    >>                 think it is not possible for these
>>>    applications to
>>>    >>                 work correctly today – which obviously is not
>>>    the
>>>    >>                 case.
>>>    >>
>>>    >>
>>>    >>
>>>    >>                     Les
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 From: Robert Raszuk <robert@xxxxxxxxxx>
>>>    >>                 Sent: Monday, November 11, 2024 2:16 PM
>>>    >>                 To: Les Ginsberg (ginsberg) <
>>>    ginsberg@xxxxxxxxx>
>>>    >>                 Cc: Acee Lindem <acee.ietf@xxxxxxxxx>;
>>>    Christian
>>>    >>                 Hopps <chopps@xxxxxxxxxx>; Mach Chen
>>>    <mach.chen=
>>>    >>                 40huawei.com@xxxxxxxxxxxxxx>; Routing ADs <
>>>    >>                 rtg-ads@xxxxxxxx>; rtg-dir@xxxxxxxx;
>>>    >>                 draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr <
>>>    >>                 lsr@xxxxxxxx>; last-call <last-call@xxxxxxxx>
>>>    >>                 Subject: Re: [Lsr] RtgDir Last Call Review:
>>>    >>                 draft-ietf-lsr-multi-tlv-06
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 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
>>>    >>                       3 octets of default metric
>>>    >>                       1 octet of length of sub-TLVs
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 Now your draft makes an impression that there
>>>    are
>>>    >>                 also at the TLV level itself optional link
>>>    >>                 identifiers.
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 4.1.  Example: Extended IS Reachability
>>>    >>
>>>    >>                    As an example, consider the Extended IS
>>>    >>                 Reachability TLV (type 22).
>>>    >>                    A neighbor in this TLV is specified by:
>>>    >>
>>>    >>                    *  7 octets of system ID and pseudonode
>>>    number
>>>    >>
>>>    >>                    *  3 octets of default metric
>>>    >>
>>>    >>                    *  Optionally one or more of the following
>>>    link
>>>    >>                 identifiers:
>>>    >>
>>>    >>
>>>    >>
>>>    >>                       -  IPv4 interface address and IPv4
>>>    neighbor
>>>    >>                 address as specified
>>>    >>                          in [RFC5305]
>>>    >>
>>>    >>                       -  IPv6 interface address and IPv6
>>>    neighbor
>>>    >>                 address as specified
>>>    >>                          in [RFC6119]
>>>    >>
>>>    >>                       -  Link Local/Remote Identifiers as
>>>    specified
>>>    >>                 in [RFC5307]
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 Can you point to the text in RFC5305 where
>>>    such IPv4
>>>    >>                 link identifier is defined ?
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 I can only find them to be defined as part of
>>>    >>                 sub-TLVs.
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 Also I do not see them as LSDB keys in FRR
>>>    ISIS code
>>>    >>                 ...
>>>    >>
>>>    >>                 Ref: https://github.com/FRRouting/frr/blob/
>>>    master/
>>>    >>                 isisd/isisd.c
>>>    >>
>>>    >>
>>>    >>
>>>    >>                 Thx,
>>>    >>
>>>    >>                 R.
>>>    >>
>>>    >>
>>>    >>
>>>    >>                     From: Acee Lindem <acee.ietf@xxxxxxxxx>
>>>    >>                     Sent: Monday, November 11, 2024 1:42 PM
>>>    >>                     To: Robert Raszuk <robert@xxxxxxxxxx>
>>>    >>                     Cc: Christian Hopps <chopps@xxxxxxxxxx>;
>>>    Mach
>>>    >>                     Chen <mach.chen=
>>>    40huawei.com@xxxxxxxxxxxxxx>;
>>>    >>                     Routing ADs <rtg-ads@xxxxxxxx>;
>>>    rtg-dir@xxxxxxxx;
>>>    >>                     draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr
>>>    <
>>>    >>                     lsr@xxxxxxxx>; last-call <
>>>    last-call@xxxxxxxx>
>>>    >>                     Subject: Re: [Lsr] RtgDir Last Call
>>>    Review:
>>>    >>                     draft-ietf-lsr-multi-tlv-06
>>>    >>
>>>    >>
>>>    >>
>>>    >>                     Speaking as WG member:
>>>    >>
>>>    >>
>>>    >>
>>>    >>                         On Nov 11, 2024, at 15:21, Robert
>>>    Raszuk <
>>>    >>                         robert@xxxxxxxxxx> 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
>>>    are
>>>    >>                         designed to also help operators to run
>>>    and
>>>    >>                         troubleshoot network problems. Or
>>>    maybe say
>>>    >>                         wireshark or tcpdump developers to
>>>    properly
>>>    >>                         decode stuff which shows up on the
>>>    wire ...
>>>    >>
>>>    >>
>>>    >>
>>>    >>                         And if this is so obvious, what is the
>>>    >>                         problem for someone with such
>>>    experience to
>>>    >>                         sit down and write down a BCP
>>>    >>                         dict listing what in his opinions
>>>    should be
>>>    >>                         used as a key for each TLV listed in
>>>    section
>>>    >>                         8.2 ? If done weeks before we would
>>>    not have
>>>    >>                         such discussion.
>>>    >>
>>>    >>
>>>    >>
>>>    >>                     If done correctly, this document would be
>>>    >>                     welcomed. However, it should be a gating
>>>    factor
>>>    >>                     on specification of IS-IS MP-TLVs.
>>>    >>
>>>    >>
>>>    >>
>>>    >>                     Thanks,
>>>    >>
>>>    >>                     Acee
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>
>>>    >>                         Kind regards,
>>>    >>
>>>    >>                         Robert
>>>    >>
>>>    >>
>>>    >>
>>>    >>                         On Mon, Nov 11, 2024 at 9:05 PM
>>>    Christian
>>>    >>                         Hopps <chopps@xxxxxxxxxx> wrote:
>>>    >>
>>>    >>                             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 DB of
>>>    >>                             neighbors) based on the TLV metric
>>>    value.
>>>    >>                             This really is obvious when people
>>>    stop
>>>    >>                             treating the discussion as some
>>>    >>                             abstraction which is again what
>>>    people
>>>    >>                             keep pointing out.
>>>    >>
>>>    >>                             Thanks,
>>>    >>                             Chris.
>>>    >>
>>>    >>                             > On Nov 11, 2024, at 08:13,
>>>    Robert
>>>    >>                             Raszuk <robert@xxxxxxxxxx> wrote:
>>>    >>                             >
>>>    >>                             > 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
>>>    >>                             folks questioning the WGLC and
>>>    >>                             progressing the document do have a
>>>    valid
>>>    >>                             point.
>>>    >>                             >
>>>    >>                             > The document by its title and by
>>>    >>                             section 8.2 creates an impression
>>>    that it
>>>    >>                             is a universal spec for all TLVs
>>>    in
>>>    >>                             respect how to implement MP-TLVs
>>>    for
>>>    >>                             them.
>>>    >>                             >
>>>    >>                             > Yet we clearly see from examples
>>>    >>                             provided in sections 4.1 and 4.2
>>>    that
>>>    >>                             what constitutes a "key" is TLV
>>>    dependent
>>>    >>                             and it is really cherry picked out
>>>    of the
>>>    >>                             number of values carried in a TLV.
>>>    >>                             >
>>>    >>                             > An example from section 4.1:  In
>>>    TLV 22
>>>    >>                             - 3 octets of def metric is
>>>    skipped and
>>>    >>                             not considered as a key
>>>    >>                             >
>>>    >>                             > An example from section 4.2: In
>>>    TLV 135
>>>    >>                             -  4 octets of metric information
>>>    and two
>>>    >>                             bits of control information octet
>>>    are
>>>    >>                             skipped and not considered as a
>>>    key
>>>    >>                             >
>>>    >>                             > So if an implementer takes this
>>>    >>                             document and attempts to write up
>>>    MP-TLV
>>>    >>                             how is he going to figure out
>>>    which
>>>    >>                             values for all other listed TLVs
>>>    in 8.2
>>>    >>                             constitute a key and which not ?
>>>    >>                             >
>>>    >>                             > IMO this document can proceed
>>>    however
>>>    >>                             only in respect to TLV 22 and TLV
>>>    135 and
>>>    >>                             both its title and content should
>>>    reflect
>>>    >>                             this.
>>>    >>                             >
>>>    >>                             > Cheers,
>>>    >>                             > Robert
>>>    >>                             >
>>>    >>                             > On Mon, Nov 11, 2024 at 1:27 PM
>>>    >>                             Christian Hopps <chopps@xxxxxxxxxx
>>>    >
>>>    >>                             wrote:
>>>    >>                             >
>>>    >>                             > Mach Chen <mach.chen=
>>>    >>                             40huawei.com@xxxxxxxxxxxxxx>
>>>    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
>>>    >>                             to provide assistance to the
>>>    Routing ADs.
>>>    >>                             > > For more information about the
>>>    >>                             Routing Directorate, please
>>>    >>                             > > see https://wiki.ietf.org/en/
>>>    group/
>>>    >>                             rtg/RtgDir
>>>    >>                             > >
>>>    >>                             > > Although these comments are
>>>    primarily
>>>    >>                             for the use of the Routing ADs, it
>>>    would
>>>    >>                             > > be helpful if you could
>>>    consider them
>>>    >>                             along with any other IETF Last
>>>    Call
>>>    >>                             > > comments that you receive, and
>>>    strive
>>>    >>                             to resolve them through discussion
>>>    or by
>>>    >>                             > > updating the draft.
>>>    >>                             > >
>>>    >>                             > > Document: https://
>>>    >>                             datatracker.ietf.org/doc/
>>>    >>                             draft-ietf-lsr-multi-tlv-06
>>>    >>                             > > Reviewer: Mach Chen
>>>    >>                             > > Review Date: 2024-11-11
>>>    >>                             > > IETF LC End Date:
>>>    >>                             > > Intended Status: Standards
>>>    Track
>>>    >>                             > >
>>>    >>                             > > Summary:
>>>    >>                             > > • I have some major and minor
>>>    >>                             concerns about this document that
>>>    I think
>>>    >>                             should be resolved before
>>>    publication.
>>>    >>                             > >
>>>    >>                             > > Comments:
>>>    >>                             > > • The document is well written
>>>    and
>>>    >>                             easy to read it.
>>>    >>                             > >
>>>    >>                             > > Major Issues:
>>>    >>                             > > 1. The definitions of the
>>>    'Key' for
>>>    >>                             TLVs and sub-TLVs vary, and this
>>>    document
>>>    >>                             > > does not specify the Key for
>>>    each
>>>    >>                             MP-TLV. Therefore, it may result
>>>    in
>>>    >>                             > > interoperability issues if
>>>    >>                             implementations use different
>>>    information
>>>    >>                             to
>>>    >>                             > > construct the 'Key.' Given
>>>    Section
>>>    >>                             8.2 listed all existing applicable
>>>    >>                             MP-TLVs,
>>>    >>                             > > it's essential to specify the
>>>    Key for
>>>    >>                             each of those MP-TLVs, either
>>>    within this
>>>    >>                             > > document or in a separate
>>>    document to
>>>    >>                             which this document should provide
>>>    a
>>>    >>                             > > normative reference.
>>>    >>                             >
>>>    >>                             > Hi Mach,
>>>    >>                             >
>>>    >>                             > I'm curious if you also followed
>>>    along
>>>    >>                             on the extensive discussions on
>>>    this
>>>    >>                             exact issue on the LSR list or
>>>    not?
>>>    >>                             >
>>>    >>                             > Understanding your exposure to
>>>    this
>>>    >>                             would help with how to address any
>>>    >>                             remaining confusion about this
>>>    directly
>>>    >>                             in the draft.
>>>    >>                             >
>>>    >>                             > 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; however, documenting that
>>>    choice and
>>>    >>                             the reasoning better may still be
>>>    >>                             necessary.
>>>    >>                             >
>>>    >>                             > So my question is this: were you
>>>    >>                             following along with this
>>>    discussion in
>>>    >>                             the LSR WG and find yourself
>>>    disagreeing
>>>    >>                             with the WG decision, or is this
>>>    entire
>>>    >>                             topic new to you?
>>>    >>                             >
>>>    >>                             > Thanks,
>>>    >>                             > Chris.
>>>    >>                             >
>>>    >>                             >
>>>    >>                             > >
>>>    >>                             > > Minor Issues:
>>>    >>                             > > 1. The MP-TLV Capability
>>>    >>                             Advertisement is defined as a
>>>    node-based
>>>    >>                             capability
>>>    >>                             > > rather than on a per-codepoint
>>>    basis,
>>>    >>                             which limits its usefulness. In
>>>    some
>>>    >>                             > > cases, it may even be
>>>    misleading if
>>>    >>                             operators just rely on this
>>>    capability to
>>>    >>                             > > assume MP-TLV support.
>>>    Therefore, it
>>>    >>                             would be preferable to either
>>>    remove this
>>>    >>                             > > capability advertisement or
>>>    redefine
>>>    >>                             it to operate on a per-codepoint
>>>    basis.
>>>    >>                             > >
>>>    >>                             > > Best regards,
>>>    >>                             > > Mach
>>>    >>                             >
>>>    >>                             >
>>>    >>                           
>>>     _______________________________________________
>>>    >>                             > Lsr mailing list -- lsr@xxxxxxxx
>>>    >>                             > To unsubscribe send an email to
>>>    >>                             lsr-leave@xxxxxxxx
>>>    >>
>>>    >>
>>>    >>
>>>    >>             _______________________________________________
>>>    >>             Lsr mailing list -- lsr@xxxxxxxx
>>>    >>             To unsubscribe send an email to lsr-leave@xxxxxxxx
>>>    >>
>>>    >>     _______________________________________________
>>>    >>     Lsr mailing list -- lsr@xxxxxxxx
>>>    >>     To unsubscribe send an email to lsr-leave@xxxxxxxx
>>> 
>> 
>> [[End of PGP Signed Part]]
> 
> _______________________________________________
> Lsr mailing list -- lsr@xxxxxxxx
> To unsubscribe send an email to lsr-leave@xxxxxxxx


-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux