Speaking as WG member: I agree totally with Ketan and, at least in my case, stems from the fact that I’m less familiar with IS-IS than OSPF.
If there are WG participants who have both the IS-IS expertise and bandwidth, this might be a good topic for an informational draft. We certainly shouldn’t stale this work as documenting the vagaries of IS-IS wasn’t within original purpose or scope of this document. Thanks, Acee > On Oct 24, 2024, at 12:28, Ketan Talaulikar <[email protected]> wrote: > > FWIW those were the reasons why I am supporting publication of this > document after raising the same question originally. > > I think those that are still raising Qs about the "lack of clarity" on > keys should look over the specific TLVs/sub-TLVs and identify what is > not clear. I did that for a good chunk (what I felt were important and > with potential to "grow large") to satisfy myself and I encourage > others that have doubts to do the same. > > If there is something really unclear, we can solve those individual > issues rather than stalling this work. > > Thanks, > Ketan > > On Thu, Oct 24, 2024 at 9:27 PM Les Ginsberg (ginsberg) > <[email protected]> wrote: >> >> Changwang – >> >> >> >> Thanx for the good summary – comments inline. >> >> >> >> From: linchangwang <[email protected]> >> Sent: Thursday, October 24, 2024 4:47 AM >> To: Les Ginsberg (ginsberg) <[email protected]>; Dongjie (Jimmy) >> <[email protected]>; Aijun Wang <[email protected]>; 'Christian >> Hopps' <[email protected]> >> Cc: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' >> <[email protected]>; [email protected]; 'lsr' >> <[email protected]> >> Subject: Re: [Lsr] Re: Re: Re: It's time to find one general solution to >> Big-TLV problem Re: IETF 121 LSR Slot Requests >> >> >> >> Hi Les, >> >> >> >> My understanding is that the current discussion mainly centers on two >> points, which easily leads to a loop: >> >> 1.MP-TLV requires a key; multiple MP-TLVs combine non-key content. >> >> 2.The key of MP-TLV is not new; it is implicitly defined in the original >> TLV, so it does not need to be defined within the MP-TLV. >> >> [LES:] Keys are explicitly(not implicitly) defined in the RFCs which define >> each codepoint. You won’t find the work “key” in these RFCs – but any >> codepoint that is used to advertise multiple objects of the same type has to >> include enough information to identify the object. >> >> >> >> From an implementation perspective, regardless of the presence of MP-TLV, >> vendors need to use a key for storing and generating TLVs in their code. >> >> [LES:] Yes >> >> >> >> When generating LSDB, TEDB, or BGP-LS, a key is used for maintenance. >> >> [LES:] I don’t know what you mean by “maintenance”. >> >> The key is part of entries in each database because without it the entries >> are incomplete. >> >> >> >> Therefore, all TLVs inherently have keys. >> >> [LES:] Yes – though the nature of the key may vary. >> >> For TLVs which support multiple objects of the same type (e.g., prefixes) >> the key is what differentiates one object from another. >> >> For TLVs which simply support a list of information (e.g., BFD Enabled TLV) >> the codepoint is the key. >> >> For some sub-TLVs, the key may be contained in the parent TLV. >> >> This is discussed in the draft. >> >> >> >> However, with an MP-TLV mechanism in place, explicitly stating the key would >> facilitate better implementation and interoperability across vendors. >> >> >> >> Recommendations： >> >> Now that there is an MP mechanism, can the MP-TLV key be displayed like in >> examples 4.1 and 4.2 of >> https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-4, >> >> listing recommended keys for all TLVs that support MP to enable better >> implementation and interoperability? >> >> When new MP-TLVs are added in the future, a column for key explanation can >> also be included." >> >> >> >> [LES:] This was considered (and discussed publicly) but rejected – for a >> number of good reasons: >> >> >> >> 1)The best we could do would be to be consistent with the source RFCs – >> which means the info would be redundant – yet because different words were >> used subject to a different interpretation by readers – clearly undesirable >> >> 2)The worst we could do is to (unintentionally) be inconsistent with the >> source RFCs – leading to confusion and interoperability issues >> >> 3)Given the large number of codepoints involved it would bloat the draft >> >> 4)It isn’t extensible i.e., when new codepoints are defined we would have to >> update the MP-TLV draft as well – or have things in the odd state that >> codepoints defined prior to publication of MP-TLV are documented one way >> while codepoints defined after publication of MP-TLV are documented in >> another way >> >> 5)It suggests that MP-TLV has introduced changes to the encoding of TLVs >> when in fact it has not >> >> (Give me some more time I could likely come up with other drawbacks. 😊 ) >> >> >> >> HTH >> >> >> >> Les >> >> >> >> >> >> Thanks, >> >> Changwang >> >> >> >> 发件人: Les Ginsberg (ginsberg) <[email protected]> >> 发送时间: 2024年10月24日 14:14 >> 收件人: Dongjie (Jimmy) <[email protected]>; Aijun Wang >> <[email protected]>; 'Christian Hopps' <[email protected]> >> 抄送: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' >> <[email protected]>; [email protected]; 'lsr' >> <[email protected]> >> 主题: RE: [Lsr] Re: 答复: Re: It's time to find one general solution to Big-TLV >> problem Re: IETF 121 LSR Slot Requests >> >> >> >> Jie – >> >> >> >> I’ll preface this by saying that if you were familiar with an implementation >> of TLV processing, I don’t think you would be asking these questions – you >> would be able to relate what has been discussed to code – and things would >> be obvious. >> >> Which is one reason I have emphasized that the validity of the draft content >> is supported by multiple implementations. We haven’t just conducted a >> “thought experiment”. >> >> >> >> We could use any TLV that is marked as potentially requiring MP support as >> an example – but let’s stick with the neighbor TLV. It’s a good example and >> one most folks are familiar with. >> >> And let’s discuss this without considering MP – because this will >> demonstrate why the addition of MP requires no additional specification for >> the neighbor TLV. >> >> >> >> When a node receives multiple neighbor TLVs from a given source, it has to >> parse them for the tuple (systemid+pseudo-node id, link identifiers). >> >> Why? >> >> Because it has to build a database of links in the network. To build this >> database it has to be able to identify one link from another - which >> requires parsing the tuple. The database will then be used in a number of >> ways: >> >> >> >> It is used as part of the SPF calculation >> It is used by traffic engineering as the raw data to build constrained paths >> >> Etc. >> >> >> >> It is also true that there are transient cases where the advertisement of a >> neighbor may move from one LSP to another (for example if an additional >> sub-TLV is required and there isn’t enough space in the LSP which has the >> existing advertisement). >> >> Because there is no guarantee that changes to multiple LSPs will be received >> “atomically”, even in the absence of MP a receiver may temporarily have two >> advertisements for the same link and it has to be able to recognize that >> state. >> >> >> >> If the tuple were not sufficient to allow an implementation to differentiate >> one neighbor advertisement from others it receives from the same source >> node, then we would have a gap in the existing specifications which would >> already have manifested itself as a problem in existing deployments. >> >> So, what is referred to as a “key” in the draft isn’t new – and its use >> isn’t new . >> >> >> >> The only thing which is new is that when MP is enabled, it is now possible >> to receive multiple TLVs for the same link outside of the transient case >> discussed above. Implementations now have to treat the TLV content as >> “additive” whereas previously they would treat the TLVs as “competing” and >> would have to choose which one they would use and which one they would >> ignore. This is discussed in >> https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-5 >> >> >> >> As for the case you mention below, where a non-key field which is present in >> every neighbor TLV (metric) differs in two different TLVs which have the >> same key, this is a pathological case which is also discussed in >> https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-5 >> >> >> >> All of this is already understood by implementations today because it is >> necessary to properly process TLVs even in the absence of MP. >> >> >> >> Existing specifications are clear as to what is a key for a given TLV. They >> have to be or we would have interoperability problems even without MP. >> >> If there actually is a case where this is not true, then it isn’t an MP >> problem – it is a deficiency in the protocol independent of MP and would >> have to be addressed as such. The correct thing to do would be to report it >> as an Errata against the appropriate RFC. >> >> >> >> Les >> >> >> >> From: Dongjie (Jimmy) <[email protected]> >> Sent: Wednesday, October 23, 2024 8:30 PM >> To: Les Ginsberg (ginsberg) <[email protected]>; Aijun Wang >> <[email protected]>; 'Christian Hopps' <[email protected]> >> Cc: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' >> <[email protected]>; [email protected]; 'lsr' >> <[email protected]> >> Subject: RE: [Lsr] Re: 答复: Re: It's time to find one general solution to >> Big-TLV problem Re: IETF 121 LSR Slot Requests >> >> >> >> Hi Les and Aijun, >> >> >> >> I’d like to share some personal views on the “key” stuff. >> >> >> >> For each IS-IS TLV/sub-TLV type , the “key” is embedded in the existing >> information of the TLV, and it may consist of multiple fields. In my >> understanding, for most of the TLVs the key fields are not explicitly >> specified. >> >> >> >> Without clear specification of the key fields, it could still be easy to >> differentiate two TLVs of the same type, as long as one of the key fields >> are different (which can be apparent to implementers). However, it would be >> relatively difficult to determine whether two TLVs of the same type can be >> concatenated or not. >> >> >> >> Section 4.1 of draft-ietf-lsr-multi-tlv uses TLV 22 as an example, it says: >> >> >> >> “The key consists of the 7 octets of system ID and pseudonode number >> plus the set of link identifiers which are present.” >> >> >> >> Thus the “default metric” field is considered as non-key, but it will be >> carried in every piece of the TLVs which need to be concatenated by the >> receiver. Should the receiver compare the default metric field of the TLVs >> received? If the TLVs have different “default metric” value, can they still >> be concatenated? If so, which value should be used for the combined TLV? >> >> >> >> For other TLVs, similar question can be raised. >> >> >> >> I fully agree the key is codepoint specific, while it just shows that more >> specification is needed to ensure consistent understanding about the >> processing of the key and non-key fields in TLV concatenation. That is why >> during the WG LC I suggested that this document either adds more >> specifications about the key fields and processing for other TLVs (as it did >> for TLV 22 and 135 in section 4), alternatively it may consider to reduce >> the scope of the applicability to the TLVs shown in the IANA section. >> Without clear specification of the key, non-key and the processing for those >> TLVs, there will be risk in interoperation. >> >> >> >> Best regards, >> >> Jie >> >> >> >> From: Les Ginsberg (ginsberg) [mailto:[email protected]] >> Sent: Wednesday, October 23, 2024 3:36 PM >> To: Aijun Wang <[email protected]>; 'Christian Hopps' >> <[email protected]> >> Cc: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' >> <[email protected]>; [email protected]; 'lsr' >> <[email protected]> >> Subject: RE: [Lsr] Re: 答复: Re: It's time to find one general solution to >> Big-TLV problem Re: IETF 121 LSR Slot Requests >> >> >> >> Ahhh…well…I am reminded of why I stopped engaging in these discussions. >> >> Sigh… >> >> >> >> If it were true ( as Aijun claims) that existing RFCs do not clearly define >> the “key” for the codepoints defined in that document, then it would not be >> possible for an implementation to correctly/reliably differentiate the >> objects described in two different TLVs of the same type – even in the >> absence of MP. >> >> This would mean that IS-IS is completely broken. >> >> >> >> I am well past my quota for discussing nonsense – so no more from me. >> >> >> >> Les >> >> >> >> >> >> From: Aijun Wang <[email protected]> >> Sent: Tuesday, October 22, 2024 11:31 PM >> To: Les Ginsberg (ginsberg) <[email protected]>; 'Christian Hopps' >> <[email protected]> >> Cc: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' >> <[email protected]>; [email protected]; 'lsr' >> <[email protected]> >> Subject: 答复: [Lsr] Re: 答复: Re: It's time to find one general solution to >> Big-TLV problem Re: IETF 121 LSR Slot Requests >> >> >> >> Hi, Les and members of the WG: >> >> >> >> Let’s try to move forward and get more constructive results for the >> discussions. >> >> >> >> First, I want to emphasize that I fully understand the current MP-TLV >> solution(I think many experts have also understood), and know the mentioned >> “key” fields are existing(or optional existing) in the current encoding of >> each IS-IS TLV. >> >> But, as mentioned by Les, “What constitutes a key is codepoint specific”, >> and there is no any RFC document such information. >> >> Current MP-TLV proposal gives such information only (“What constitutes a >> key”) for two TLVs(“IS-Neighbor TLVs“ and “Prefix Reachability TLV“)，but >> none for others( for example “BFD Enabled TLV“ that provided by Les in this >> mail as another possible big IS-IS TLV example), let alone all the possible >> big IS-IS TLVs. >> >> >> >> Lacking the definition of “What constitutes a key” CANNOT certainly achieve >> the aim of “treating two TLVs for the same object as additive rather than as >> replacements for each other”, in other words, glue the sliced IS-IS TLVs >> together. >> >> The last sentence is my main argue point for the current MP-TLV proposal. >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> >> >> , >> >> 发件人: [email protected] [mailto:[email protected]] 代表 >> Les Ginsberg (ginsberg) >> 发送时间: 2024年10月23日 13:23 >> 收件人: Aijun Wang <[email protected]>; 'Christian Hopps' >> <[email protected]> >> 抄送: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' >> <[email protected]>; [email protected]; 'lsr' >> <[email protected]> >> 主题: [Lsr] Re: 答复: Re: It's time to find one general solution to Big-TLV >> problem Re: IETF 121 LSR Slot Requests >> >> >> >> Soooo....for the benefit of the WG... >> >> >> >> Aijun has sent many messages making the same claims. In the past I (and >> others) have made attempts to explain to Aijun why he is mistaken. >> >> For one example see >> https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/ >> >> >> >> None of these responses have convinced Aijun that he is mistaken - so I do >> not expect that this response will alter his opinion. In fact, I fully >> expect that in response to this email Aijun will send yet another email >> making the same mistaken claims. 😊 >> >> >> >> But I am not sending this in the hopes of altering Aijun's understanding. >> >> I am sending this only to reassure other members of the WG who might not be >> as familiar with the solution defined in >> https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ that what Aijun >> is claiming is incorrect. >> >> >> >> No encoding changes to any codepoint are required for the multi-tlv >> solution. This is a hallmark of the solution as it ensures that >> implementations can use existing code for encoding the TLVs they send and >> use existing code for parsing the TLVs they receive. >> >> The only implementation changes which are required have to do with treating >> two TLVs for the same object as additive rather than as replacements for >> each other. This is described in more detail in >> https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-5 >> >> >> >> What seems to have confused Aijun is the use of the generic term "key" to >> describe that portion of a given codepoint which uniquely identifies the >> object associated with a given TLV. This isn't the introduction of new >> information - it is simply a generic term for what is already being >> advertised in TLVs and in fact already being processed on receive even in >> the absence of MP. What constitutes a key is codepoint specific - but it is >> not new information that is required when MP is in use. For example: >> >> >> >> For IS-Neighbor TLVs the "key" is system-id and link identifiers (as >> described in >> https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-4.1 >> ) >> >> For Prefix Reachability TLVs the "key" is the prefix/length (as described in >> https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-4.2 >> ) >> >> For the BFD Enabled TLV the key is (MTID,NLPID). >> >> Etc. >> >> >> >> The fact that we did not describe in the draft the "key" for all codepoints >> for which MP-TLV is applicable does not mean that additional information is >> required to be sent in those codepoints when MP-TLV is in use. >> >> This is a fundamental misunderstanding. >> >> >> >> As I mentioned in a previous post, we have running code from multiple >> vendors which prove that what I say above is correct. >> >> Claims to the contrary indicate only that the person making those claims >> does not understand the draft. >> >> >> >> Thanx for listening. >> >> >> >> Les >> >> >> >> >> >>> -----Original Message----- >> >>> From: Aijun Wang <[email protected]> >> >>> Sent: Tuesday, October 22, 2024 8:53 PM >> >>> To: 'Christian Hopps' <[email protected]> >> >>> Cc: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' >>> <[email protected]>; >> >>> [email protected]; 'lsr' <[email protected]> >> >>> Subject: [Lsr] 答复: Re: It's time to find one general solution to Big-TLV >> >>> problem Re: IETF 121 LSR Slot Requests >> >>> >> >>> Hi, Chris: >> >>> >> >>> Thanks for sharing your thoughts for the past discussions. >> >>> The reason that the previous Big-TLV proposal doesn't win the debates in >>> past >> >>> is that it has the same "key" definitions requirements for every possible >>> big IS- >> >>> IS TLV, as that in the current approach of MP-TLV solution. >> >>> >> >>> But, the above "key" definition for every possible big IS-IS TLV >>> requirements >> >>> DOESN'T EXIST now, then the updated Big-TLV proposal has the obvious >> >>> advantage over the current MP-TLV solution. >> >>> It's time to reevaluate the two approaches within the WG. >> >>> >> >>> The main challenge for the MP-TLV approach is that it still requires the >>> specific >> >>> "key" definition for each possible big IS-IS TLV, which is non-extensible, >>> non- >> >>> deployable/operational(considering its ambiguous declaration of "MP-TLV >> >>> capabilities" is type independent instead). >> >>> >> >>> Best Regards >> >>> >> >>> Aijun Wang >> >>> China Telecom >> >>> >> >>> -----邮件原件----- >> >>> 发件人: [email protected] [mailto:[email protected]] >> >>> 代表 Christian Hopps >> >>> 发送时间: 2024年10月23日 10:57 >> >>> 收件人: Aijun Wang <[email protected]> >> >>> 抄送: 【外部账号】Christian Hopps <[email protected]>; Yingzhen Qu >> >>> <[email protected]>; lsr-chairs <[email protected]>; draft-wang-lsr- >> >>> [email protected]; lsr <[email protected]> >> >>> 主题: [Lsr] Re: It's time to find one general solution to Big-TLV problem Re: >> >>> IETF 121 LSR Slot Requests >> >>> >> >>> >> >>> Hi Aijun, >> >>> >> >>> [as-wg-member]: Perhaps you don't recall, but if you go review all the email >> >>> threads and presentations/video you will see that I was a supporter of >> >>> Huaimo's idea originally. >> >>> >> >>> [as-wg-member]: However, I also accepted that I was "in the rough" and the >> >>> WG did not agree with using a new TLV for this problem. The WG has a >> >>> different solution that you do not agree with, but that doesn't change the >>> WG >> >>> rough consensus. >> >>> >> >>> Thanks, >> >>> Chris. >> >>> >> >>> Aijun Wang <[email protected]> writes: >> >>> >> >>>> Hi,Chris: >> >>>> >> >>>> Please elaborate clearly your technical reviews for the updates of the >> >>>> newly proposed Big-TLV solution. >> >>>> >> >>>> I can copy the updates again at here and state their effects clearly. >> >>>> (https://mailarchive.ietf.org/arch/msg/lsr/ >> >>>> dxK4Gy1WDR7QCXK6p58xgA0MdUc/ )Please give your analysis before you >> >>>> make any conclusions: >> >>>> >> >>>> >> >>>> A new version of Big-TLV document has been >> >>> posted(https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-big-tlv), >>> to >> >>> try to give the community one general way to solve the Big TLV problem. >> >>>> >> >>>> The main changes from the previous versions are the followings: >> >>>> 1) Add one "Identification" field within the container TLV(type TBD1), to >> >>> function as the key for any sliced TLV, and is TLV code point independent. >> >>>> 2) Add one "Flag" field, define currently the "F" bit to indicate >> >>>> whether the piece of container is the first piece(F bit is set to 1), >> >>>> or not (F bit is unset) >> >>>> 3) Put all the sliced pieces within the newly defined container TLV(type >> >>> TBD1). >> >>>> 4) Define some rules for the "Split and Glue" procedures(may be >> >>>> re-optimizer later after the WG discussions) >> >>>> >> >>>> The updated version erases the necessity of defining the "key" information >> >>> for every IS-IS (Possible Big) TLV code point, and also the necessity of >>> per-TLV >> >>> capability announcement. >> >>>> >> >>>> >> >>>> I would like to hear your detail analysis, especially as the WG chairs, >>>> for the >> >>> above statements. >> >>>> >> >>>> Aijun Wang >> >>>> China Telecom >> >>>> >> >>>> >> >>>> On Oct 22, 2024, at 20:15, 【外部账号】Christian Hopps >> >>>> <[email protected]> wrote: >> >>>> >> >>>> >> >>>> Those changes don't appear to address what the WG already decided >> >>>> against. The view of the WG was that a new Big TLV for doing this >> >>>> was not going to work. Given the name of this work is Big TLV, >> >>>> that doesn't seem to have changed. So why should the WG be >> >>>> spending even more time on a solution they already discussed, >> >>>> debated and discarded? >> >>>> >> >>>> Thanks, >> >>>> Chris. >> >>>> [as wg chair] >> >>>> >> >>>> >> >>>> >> >>>> On Oct 22, 2024, at 06:47, Aijun Wang >> >>>> <[email protected]> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Hi, Chris: >> >>>> >> >>>> >> >>>> >> >>>> No, we have made some significant updates. >> >>>> >> >>>> Please refer to https://mailarchive.ietf.org/arch/msg/lsr/ >> >>>> dxK4Gy1WDR7QCXK6p58xgA0MdUc/ for more information. >> >>>> >> >>>> >> >>>> >> >>>> Aijun Wang >> >>>> >> >>>> China Telecom >> >>>> >> >>>> >> >>>> >> >>>> On Oct 22, 2024, at 17:04, 【外部账号】Christian Hopps >> >>>> <[email protected]> wrote: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Is this the same thing that Huaimo has already presented >> >>>> to the WG, that the WG decided was not the way it wanted >> >>>> to go? >> >>>> >> >>>> >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Chris. >> >>>> >> >>>> >> >>>> >> >>>> "Aijun Wang" <[email protected]> writes: >> >>>> >> >>>> >> >>>> >> >>>> Hi, Yingzhen: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> I would like to request 10-15minutes to make the >> >>>> presentation for the >> >>>> >> >>>> “IS-IS Extension for Big TLV” >> >>>> >> >>>> >> >>>> >> >>>> The related information are the followings: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Draft Name: IS-IS Extension for Big TLV >> >>>> >> >>>> >> >>>> >> >>>> Link: https://datatracker.ietf.org/doc/ >> >>>> draft-wang-lsr-isis-big-tlv >> >>>> >> >>>> / >> >>>> >> >>>> >> >>>> >> >>>> Presenter: Aijun Wang >> >>>> >> >>>> >> >>>> >> >>>> Desired Slot Length: 10-15minutes. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Best Regards >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Aijun Wang >> >>>> >> >>>> >> >>>> >> >>>> China Telecom >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> 发件人: [email protected] >> >>>> >> >>>> [mailto:[email protected]] 代表 Yingzhen >> >>>> Qu >> >>>> >> >>>> 发送时间: 2024年10月12日 3:54 >> >>>> >> >>>> 收件人: lsr <[email protected]>; lsr-chairs >> >>>> <[email protected]> >> >>>> >> >>>> 主题: [Lsr] IETF 121 LSR Slot Requests >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Hi, >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> The draft agenda for IETF 121 has been posted: >> >>>> >> >>>> >> >>>> >> >>>> IETF 121 Meeting Agenda >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> The LSR session is scheduled on Thursday Session I >> >>>> 09:30-11:30, Nov 7th, 2024. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Please send slot requests to [email protected] >> >>>> before the end of the day >> >>>> >> >>>> >> >>>> >> >>>> Wednesday Oct 23. Please include draft name and >> >>>> link, presenter, desired >> >>>> >> >>>> >> >>>> >> >>>> slot length including Q&A. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Thanks, >> >>>> >> >>>> >> >>>> >> >>>> Yingzhen >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Lsr mailing list -- [email protected] >> >>> To unsubscribe send an email to [email protected] >> >> ------------------------------------------------------------------------------------------------------------------------------------- >> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 >> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 >> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 >> 邮件！ >> This e-mail and its attachments contain confidential information from New >> H3C, which is >> intended only for the person or entity whose address is listed above. Any >> use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender >> by phone or email immediately and delete it! >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
