2024)

Aijun Wang Wed, 28 Aug 2024 23:14:54 -0700

Hi, Les:

If the following key points can’t be solved, what the meaning to wrap around, around and around… …the wording games?

1) If there is no key definition for each MP-TLV capable codepoint, how to fragment and concatenate the sliced MP-TLV?

2) If there is no indication for the capabilities of which MP-TLV the router support(with key definition), why can one router/vendor declare false positively for it support MP-TLV, similar as that this document announces again and again false positively that it solves the MP-TLV problems?

Aijun Wang

China Telecom

On Aug 29, 2024, at 12:44, Les Ginsberg (ginsberg) <[email protected]> wrote:

Bruno –

Top posting here as I think we are down to three issues which call for further discussion.

Issue #1

Section 7.1 currently says:

“Implementations SHOULD report alarms under the following conditions:

If an MP-TLV is received when use of MP-TLVs is disabled.

If local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled.”

You would like it also to say (final wording might be different):

“If local LSP generation requires the use of MP-TLVs and not all routers in the network are advertising the MP-TLV Capability Advertisement defined in Section 7.2.”

Am I stating your request correctly?

My pushback is based on the fact that there are routers which support MP-TLV which do not send the new capability advertisement and that the Capability Advertisement does not indicate for which TLVs a given implementation supports MP-TLV.

Therefore, such an alarm could be meaningless. Also, the state of the network as regards all routers advertising the MP-TLV capability TLV could change – and could even oscillate.

I have always considered the new capability advertisement as simply a “hint” to operators.

I can imagine implementations might provide a “show mp-tlv capability” command which would allow operators to look at the current state in this regard – not something which triggers any action – and by that I consider an alarm an “action”.

But, I agree, it would be possible to add this text, if you really think it is helpful.

Please indicate this (I know you kind of already have – just wanted to be sure) and the authors can discuss.

Issue #2

Regarding keys and particularly the keys to identify a link, you are asking that the draft:

“…add a ranking (e.g., the current one) and state the highest ranked link identifier(s) SHOULD be used in subsequent MP-TLV pars.”

Two strong objections from me:

a)The draft makes no changes to the encoding rules for any codepoint. This is a fundamental part of the solution because it guarantees that each TLV in an MP-TLV set conforms to existing specifications.

b)There is no notion of ordering for the individual TLVs which are part of an “MP-TLV set”. Determining which TLV is the “first” and which is a “subsequent” is not possible.

Can we agree not to do this?

Issue #3

Regarding “keys” for new codepoints, you suggest:

“Regarding issues with new keys, that needs to be addressed by the relevant document.

[Bruno3] Fair point. But it would be good for the document to state the above for that future extensions are aware of the issue/requirement..

By requiring drafts for new codepoints to explicitly specify MP applicability in the appropriate IANA registry, we guarantee that the new document has to (at least minimally) make an explicit statement regarding MP-TLV applicability.

Also, a key is not defined because MP-TLV requires it. A key is defined because the codepoint itself requires it to identify which object is being described by the advertisement.

Making a statement in this document suggests that MP-TLV places new requirements on key definition when it does not.

Can we agree not to do this?

Les
From: [email protected] <[email protected]>
Sent: Wednesday, August 28, 2024 7:11 AM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]>
Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Les,

Thanks for your reply and the v04.

Please see inline [Bruno3]

From: Les Ginsberg (ginsberg) <[email protected]>
Sent: Wednesday, August 28, 2024 2:13 AM

Bruno –

Welcome back.

Note that V4 of the draft has just been posted to address your comments – with one exception.

<snip>

[Bruno] Let me rephrase.

OLD: If local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled

NEW: If local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled on this node or not supported on other nodes in the flooding domain (as advertised by the MP-TLV Capability Advertisement).

[LES2:] OK – I understand your point now. We can add this text.

Thanx for clarifying.

<end snip>

It is not possible to do what you asked.

[Bruno3] I think that this is possible but that authors don’t want to, which is a bit different.

But I won’t insist.

Remember that the MP-TLV Capability Advertisement is only an informational indication that an implementation supports MP-TLV for at least one codepoint. It does not indicate the full set of codepoints for which MP-TLV is supported (intentionally).

[Bruno3] I remember this, and this does not prohibit sending in alarm in log.

In addition, there are existing implementations already deployed which support MP-TLV but do not advertise the capability advertisement.

[Bruno3] I don’t see how implementation not supporting capability advertisement prohibits sending an alarm. Worst case the alarm is a false positive which can be easily filtered by the administrator (e.g. based on the name/version of the implementation which support MP-TLV but not the capability advertisement.)

This is why we have stated in the draft:

“This advertisement is for informational purposes only. Implementations MUST NOT alter what is sent or how what is received is processed based on these advertisements.”

[Bruno3] This does not prohibit writing an alarm in the log.

Additional responses inline below – look for LES3:

[Bruno3] additional responses below – look for [Bruno3]. There is only/still 1 point being opened/discussed.
From: [email protected] <[email protected]>
Sent: Tuesday, August 27, 2024 7:45 AM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]>
Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Les,

Please see inline [Bruno2]

From: Les Ginsberg (ginsberg) <[email protected]>
Sent: Friday, August 9, 2024 7:38 PM

CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender.

ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur.

Bruno –

Seems like we are converging.

[Bruno2] We are definitely progressing. This feels good.

Some additional responses inline – look for LES2:
From: [email protected] <[email protected]>
Sent: Friday, August 9, 2024 7:40 AM
To: Les Ginsberg (ginsberg) <[email protected]>
Cc: Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]>
Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Les,

From: Les Ginsberg (ginsberg) <[email protected]>
Sent: Friday, August 9, 2024 6:11 AM

Bruno –

Thanx for the detailed comments.

Thanks for taking the time to respond in detail.

Note that we have not yet fully determined what text changes should be made to the draft – but hopefully this discussion will help us move forward.

I appreciate that this discussion is time consuming – but hopefully worth it for all of us.

+1.

BTW, I will be away for a few days the first part of next week (returning on Thursday August 15) – so responses may be delayed.

No problem, thanks Les. On my side, I’ll be away till August 26

[LES2:] Now I am jealous. 😊

[Bruno2] Thanks for your patience.

Don’t be (too) jealous. If you look at the whole picture/package, the situation will look very different 😉 (e.g., more like unpaid time off)

Please see inline.
From: [email protected] <[email protected]>
Sent: Wednesday, August 7, 2024 6:03 AM
To: Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]>
Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Hi authors,

Please see below some possible comments on the draft.

1)

§3 says

“TLVs sometimes contain information, called a key, that indicates the applicability of the remaining contents of the TLV. If a router advertises multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the set of LSPs for a level with the same key value, they are considered a multi-part TLV (MP-TLV).”

I’m reading this as: TLV not having a key can’t be a MP-TLV.

If this is not the intention please clarify. (e.g. same key value if that TLV has a key)

If this is the intention, this seems to contradict with other text such as

§4 “If a Multi-part TLV contains information that specifies the applicability of its contents (i.e., a key), the key information MUST be replicated”

§6 “However, Multi-Part TLV procedures are potentially applicable to any codepoint that allows sub-TLVs to be included as part of the information advertised.”

[LES:] In order for MP-TLV to be applicable to a codepoint, there has to be the potential for more than 255 bytes of information to be advertised. (obvious 😊)

And if multiple TLVs are sent, there has to be a way to identify them as being associated with the same object (which is what the “key” does).

This is consistent with the statement “TLV not having a key can’t be a MP-TLV.”.

But there are some subtleties.

To use your example of the admin tag sub-TLVs, I agree that it is conceivable (though unlikely) that one could need to advertise more than 255 bytes of tags, yet the tag sub-TLVs themselves do not have a “key”.

Functionally however, as they are associated with a single prefix, they inherit the key from the parent codepoint.

(More comments on admin tag below).

[Bruno] OK. The principle of the MP-TLV extension is clear. My concern is that the sender be more subtle than the receiver and hence the receiver gets surprised/lost.

In summary, I think we can do a better job of wording in this section – we will work on that.

But the existing text is correct in spirit.

[Bruno] OK, thanks.

[Bruno3] addressed in -04 (comment is meant to help the shepherd)

2)

§4.1 (TLV 22)

“The key consists of the 7 octets of system ID and pseudonode number plus the link identifiers.”

OK. May be for extra clarify :s/the link identifiers/all links identifiers which are present

[LES:] We will make this change.

[Bruno3] addressed in -04 (although with a different wording)

“The following key information MUST be replicated in each of the additional Extended IS Reachability TLVs:

 7 octets of system ID and pseudonode number

 At least one of the following identifiers”

It’s not clear to me whether you mean “all link identifiers” advertised in the first part (which would seem to match your above definition of the key) or “any (number) of links identifiers”.

That’s the typical example where the lack of a formal definition of the key for a (all) TLVs may brings interop issue. One implementer could believe that all link identifiers are needed in all parts, while another could believe that a subset is enough in some cases.

[LES:] We mean exactly what we say - "at least one".

It is not necessary to advertise all of the link identifiers in each TLV in order to correctly identify the two TLVs as having the same key.

There is a good deal that could be said here - but it is not the province of this document to do so. The issue you raise is applicable to a single TLV as well.

For example, A-B have an adjacency and advertise an IS-Neighbor TLV, the following works for the purposes of doing TWCC:

A advertises: (B system-id, IPv4 endpoint addresses,   Local/Remote Link IDs)

B advertises: ( A system-id, Local/Remote IDs)

[Bruno] Thanks for the example. Really useful.

I’m fine so far, especially because A and B are different nodes so they may advertise/be configured with different things.

If it takes two TLVs for A to advertise all of the link attribute information associated with the adjacency to B, A could advertise:

TLV #1: (B system-id, IPv4 endpoint addresses, Local/Remote Link IDs)

TLV #2: (B system-id, Local/Remote Link IDs)

[Bruno] What about the following example advertised by A

TLV #1: (B system-id, IPv6 Interface Address, Local/Remote Link IDs)

TLV #2: (B system-id, IPv6 Interface Address)

With B not supporting RFC 6119 (IPv6 Interface Address)

[LES2:] For a given topology, it is required that in order for an adjacency to be formed, the set of supported address-families MUST match.

I cannot have A supporting IPV4 and IPv6 in MTID #0 – but B supporting only IPv4 – because A will want to use the link to forward IPv4 and IPv6 traffic – which B does not support.

So this case cannot arise – at least not legally.

These topological restrictions come from RFC1195 and RFC 5120.

[Bruno2] OK, wrong example on my side. Might be safer for me to reuse your own example. 😉

TLV #1: (B system-id, IPv4 endpoint addresses1, Local/Remote Link ID1)

TLV #2: (B system-id, IPv4 endpoint addresses2, Local/Remote Link ID2)

TLV #3: (B system-id, Local/Remote Link ID1)

What if B does not support Local/Remote Link IDs (RFC 5307)? How does B know whether TLV #3 is an MP-TLV of TLV #1 or #2?

And it’s not specific to Link ID. A new RFC could bring a new (sub) key.

[LES3:] Regarding linkids…this is an issue which is outside the scope of this draft.

[Bruno3] So we agree that this is an issue. Good first step.

To me, the example that I provided above is a typical issue specific to MP-TLV. Indeed, for MP-TLV to work, MP-TLV parts needs to agree on the key and in the above example, they can’t.

IMO, at least the document should acknowledge the issue so that implementors and SP are aware of it.

Then, ideally, I would prefer a (partial) solution. What about the following slight change.

§4.1 already lists the identifiers for IS Reachability TLV. We could add a ranking (e.g., the current one) and state the highest ranked link identifier(s) SHOULD be used in subsequent MP-TLV pars. (I’d probably have a preference for “MUST” for an interop issue but I’m trying to compromise)

Linkids are defined in RFC5307, specifically to address unnumbered links where a unique endpoint address is not available.

However, there is no prohibition against sending linkids for numbered links – and I am aware of implementations that do so.

If this causes an interoperability issue, such an issue is not confined to MP-TLV. I am not aware such an issue exists in deployments, but if it does, we need to address it outside the context of this draft.

Regarding issues with new keys, that needs to be addressed by the relevant document.

[Bruno3] Fair point. But it would be good for the document to state the above for that future extensions are aware of the issue/requirement..

MP-TLV does not alter the encoding of existing TLVs – which is a very important attribute of the MP-TLV solution.

It is therefore not appropriate for this draft to introduce new restrictions on the use of keys.

Possibly this is obvious to everyone but me, but I’m a priori not confident that the sender may be as creative as it want, and expect the receiver to always figure out correctly.

Receivers can still correctly identify the two TLVs as being associated with the same adjacency to B.

I agree that there are multiple cases where the receiver could correctly identify the two TLVs. My concern is that some receivers may not, even if they could. E.g. the one implementing the receiver feels like this is an optional case and no bother implementing this case.

[LES2:] This problem is not introduced by multi-tlv – so my statement directly below applies.

[Bruno2] I think MP-TLV makes this problem bigger

You may wish this was written down in some document - but multi-tlv draft is not the right place to do this. If needed, some update to RFC 5305 (et al) could be done. That is a decision for the WG to make.

3)

§5 Procedure for Receiving Multi-part TLVs

“If the internals of the TLV contain key information, then replication of the key information should be taken to indicate that subsequent data MUST be processed as if the subsequent data were concatenated after a single copy of the key information.”

May be :s/should/MUST

[LES:] We will make this change.

[Bruno] Thanks.

[Bruno3] addressed in -04

4)

§5 Procedure for Receiving Multi-part TLVs

“A TLV may contain information in its fixed part that is not part of the key. […] Having inconsistent information in different parts of a MP-TLV is an error and is out of scope for this document.”

I know that we have divergence on this aspect, but to me error handling is part of the specification. At least so that all receivers make a consistent choice.

A typical simple behavior could be to discard the whole MP-TLV (all parts). Alternatively the error handling defined in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-12#sec_isis_gen_metric

“advertisement in the lowest numbered fragment MUST be used and the subsequent instances MUST be ignored.”

Also I would welcome a more normative text. e.g. :s/is an error/ MUST be treated as an error.

[LES:] In such scenarios there is no way to know which value is "correct". Historically there have been two approaches:

1)Implementations make a local decision as to which of the values they use and/or whether to ignore both.

2)Define a deterministic behavior e.g., use the first occurrence in the lowest numbered LSP.

In cases where behavior is specified, some RFCs have chosen #1 and some have chosen #2.

But multi-tlv does not introduce this problem and therefore it is out of scope for this document to define the behavior.

[Bruno] To me multi-tlv introduces the possibility to advertise two TLV with the same key. Because of a bug, those two TLV may sent with different information in its fixed part. So it would be up to this document to handle that case.

Sorry if I’m missing something

[LES2:] Even in a single TLV, the sender could send duplicate information (remember that IS-IS allows multiple prefix advertisements (for example) to be included in a single TLV).

[Bruno3] Fair enough

[Bruno2] OK.

Not least because we would have to be

concerned with contradicting existing specifications no matter which choice was made.

If you feel this is important enough to address, then the codepoint specific documents need to be updated.

It is possible that we could say something like:

“If the relevant RFC which defines a codepoint is not explicit as to how to handle such situations, Option #2 SHOULD be followed.”

This would establish a recommended default behavior while allowing specific codepoints to override this behavior.

If you think this is helpful we can add such text.

??

[Bruno] I think that this would be helpful. At least for me. Thanks for the suggestion. But the deterministic behavior would need to be specified (,no?)

[LES2:] Yes – part of the new text would be to specify the behavior.

[Bruno3] addressed in -04

5) §7.1 Recommended Controls and Alarms

Ideally I would like the addition of the below case:

“* An MP-TLV Capability Advertisement is not received from a node when use of MP-TLVs is enabled.”

Because you can’t expect existing node to comply with “If an MP-TLV is received when use of MP-TLVs is disabled” hence this is not enough to detect the partial deployment issue.

[LES:] I am having trouble parsing this.

If the receiver receives only one TLV for a given object, there is no way for the receiver to know whether the sender had additional information to send but suppressed it or if the sender simply didn't have any additional information.

[Bruno] Let me rephrase.

OLD: If local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled

NEW: If local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled on this node or not supported on other nodes in the flooding domain (as advertised by the MP-TLV Capability Advertisement).

[LES2:] OK – I understand your point now. We can add this text.

Thanx for clarifying.

[Bruno2] Thanks.

[LES3:] As mentioned at the beginning, after further thought it was not possible to do what you suggested.

[Bruno3] Ack. Thanks for taking the time to re-disclose the change inline and for being transparent about the change.

I understand that this is extra work so I’m not insisting. But if you believe that this is not a significant extra work, I think it may help the operator during initial deployment.

What we are recommending here is that implementations inform the operator that MP-TLVs are being sent by some nodes even though the operator has disabled it on the local node. If the operator has disabled the use of MP-TLVs on a node, it is presumed that the operator had a reason to do so i.e., the operator knows that at least some nodes in the network do not support reception of MP-TLVs and so they should not be sent by any node.

The only way the operator can avoid partial deployment issues is to ensure that the configuration of any node does not require the sending of MP-TLVs.

Disabling the sending of MP-TLVs in the presence of configuration which requires more than 255 bytes to be sent for an object means that not all required info can be sent - and what will be excluded is unpredictable - so the network will be compromised.

[Bruno] Let’s suppose that new configuration is added requiring more than 255 bytes. I’m making a distinction between:

a)    Node does _not_ send MP-TLV hence some configuration is not advertised in IS-IS (whether the CLI is shown as “active” or “inactive” doesn’t seem to change anything for IS-IS). Agreed the node and the network will not behave as expected, but all nodes have a consistent view of the LSDB

b)    No sends MP-TLV while some other nodes do not support MP-TLV. à different nodes have a different view of the LSDB.

I feel that “b” is a bigger issue.

[LES2:] I won’t quibble about which issue is “bigger”. They both are problematic. Will work on text to address this point.

[Bruno2] OK. Thank you Les.

[Bruno3] somewhat addressed in -04

We could add some text to this effect in Section 7 if you think it would be helpful.

6) §7.2 MP-TLV Capability Advertisement

“Nodes which support MP-TLV for codepoints for which existing specifications do not explicitly define such support, but for which MP-TLV is applicable, SHOULD include this sub-TLV in a Router Capability TLV.”

Looks good, thank you. Yet “existing specifications” may be unclear in 5 years from now. May be you could refer to the section 8.2 which specifically list those codepoints. (since you did the effort of writing §8.2, you could reference it)

[LES:] The point of adding the MP-TLV applicability column to registries means that going forward, every new codepoint will be required to explicitly indicate whether MP-TLV applies. This will be enforced by the WG and IANA. So, it should not be possible for documents that become RFCs after this draft becomes an RFC to be "unclear".

Existing RFCs may never get updated, but hopefully we have covered those cases in Section 8.2.

So I do not share your concern.

[Bruno] ok, no problem.

7) 8.2.3. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Neighbor Information

Checking one random value.

17

Generic Metric

Y

Does this match the sub-TLV defined in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-12#sec_isis_gen_metric?

If so,

-       This seems to contradict the spec “For a particular metric type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised in TLV 22, 222, 23, 223 and 141.”, “If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric type (and same application in case of ASLA) in one or more received LSPDUs, advertisement in the lowest numbered fragment MUST be used and the subsequent instances MUST be ignored.”

-       Also it’s length is hardcoded to 4 octets. Why would one need to use MP-TLV?

[LES:] I agree – this is misidentified. We will correct that.

IINM, although I agree that sampling 1 TLV out of many is poor sampling, it’s a bit disturbing to find an error out of one TLV. At minimum it seems to indicate a lack of review from the WG.

[LES:] Disturbs me too. We tried hard to be accurate and complete, but…obviously we still need good review (like yours).

[Bruno] I wish there would be more eyes / reviewers. It’s also why I believed that adding, in this doc, the key for each TLV would allow more eyes to check that we all agree on the key definition. But I got the pusback 😉. I’m not trying to insist, but explain my initial motivation.

Picking another value

1

32-bit Administrative Tag Sub-TLV

N

Why a “No”? This sub TLV includes a set of tags and if the number of tags is large enough, it seems like a good candidate for MP-TLV, no?

[LES:] :] Conceptually I agree.

[Bruno] Thank you.

RFC 5130 does not prohibit multiple sub-TLVs - though it also does not explicitly allow them.

One could argue that 50+ 32 bit tags can be advertised in a single sub-TLV – which ought to be more than enough for any deployment.

[Bruno] +1. Especially when some implementations may only support one 😉.

But strictly speaking RFC 5130 does not prohibit this – so it could be considered as possible.

There are then two choices:

1)Mark this codepoint as MP-TLV applicable

2)Update RFC 5130 to prohibit multiple sub-TLVs/prefix

#1 can be done in this draft

#2 should be done as either an errata or bis to RFC 5130.

Make sense to you?

[Bruno] Absolutely. #1 seems easier but totally up to you. Personally a 3^rd option would also work for me “3) Maks this codepoint a non MP-TLV applicable”. Because I think that MP-TLV is introduced by this document and hence could make that choice. But I feel that your preference would be to make MP-TLV applicable to all TLVs by default whenever it’s possible.

[LES2:] I believe the 3^rd option (as you refer to it) is preferable, but it really amounts to updating RFC 5130 – which I am a bit loathe to do in this document.

I will discuss with co-authors and see what we want to do.

[Bruno3] addressed in -04 (with option #1)

--Bruno
[Bruno2] Ack. Thanks. I’m not sure I would call this updating 5130. RFC 5305 says “There is
   no defined mechanism for extending the sub-TLV space. Thus, wasting

   sub-TLV space is discouraged.” and you don’t feel the need to update 5305. Actually may be MP-TLV should be marked as updating 5305

[LES3:] I would prefer not to do so.

Other RFCs have already introduced the use of MP-TLV for specific codepoints (see MP-TLV draft Introduction) without claiming to update RFC 5305, I don’t think we should do so in this case.

   Les

--Bruno

    Les

Thank you

--Bruno

On a side note, thank you for the addition of §6 which definitely simplifies and helps interop.

[LES:] Thanx.

   Les

Thanks,

Regards,

--Bruno

From: Yingzhen Qu <[email protected]>
Sent: Tuesday, July 2, 2024 8:08 AM
To: lsr <[email protected]>; lsr-chairs <[email protected]>
Subject: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender.

ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur.
Hi,
 
This email begins a 2 week WG Last Call for the following draft: draft-ietf-lsr-multi-tlv-01 - Multi-part TLVs in IS-IS
 
Please review the document and indicate your support or objections by July 15th, 2024. 
Authors,
 
Please indicate to the list, your knowledge of any IPR related to this work.
 
Thanks,
Yingzhen
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
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]

[Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024)

Reply via email to