Ketan - Thanx for this post.
The authors have done diligence on this point. We had to review every codepoint in order to correctly build the tables in the IANA section. It is certainly possible that we missed something - so we welcome review - but it needs to be targeted i.e., a sweeping statement that there might be lack of clarity isn’t helpful. Also (repeating an important point), as MP-TLV introduces no changes in the encoding of any codepoint, any issue found would apply to both the single TLV case and the MP-TLV case and therefore would need to be addressed by correcting the RFC which defines the codepoint. Les > -----Original Message----- > From: Ketan Talaulikar <[email protected]> > Sent: Thursday, October 24, 2024 9:28 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: linchangwang <[email protected]>; Dongjie (Jimmy) > <[email protected]>; Aijun Wang <[email protected]>; > Christian Hopps <[email protected]>; Yingzhen Qu > <[email protected]>; lsr-chairs <[email protected]>; draft-wang-lsr- > [email protected]; lsr <[email protected]> > Subject: Re: [Lsr] Re: It's time to find one general solution to Big-TLV > problem > Re: IETF 121 LSR Slot Requests > > 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' <lsr- > [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' <lsr- > [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' <lsr- > [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' <lsr- > [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' <lsr- > [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' <lsr- > [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' <lsr- > [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]
