Ketan –
I have posted V15 of the draft which addresses those issues on which we have
reached agreement.
There are still some substantive issues on which we are definitely not in
agreement.
Please see my responses inline {LES2:].
(I suggest in the next email we can trim out the resolved issues – I did not do
that here for the sake of completeness.)
From: Ketan Talaulikar <ketant.i...@gmail.com>
Sent: Friday, April 11, 2025 1:45 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: The IESG <i...@ietf.org>; draft-ietf-lsr-multi-...@ietf.org;
lsr-cha...@ietf.org; lsr@ietf.org; yingzhen.i...@gmail.com
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: (with
DISCUSS and COMMENT)
Hi Les,
Thanks for your quick responses and please check inline below for follow-ups
with KT.
For the points where I haven't responded, I agree and have nothing further to
add.
On Fri, Apr 11, 2025 at 12:24 PM Les Ginsberg (ginsberg)
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote:
Ketan -
Thanx for the thorough review.
Please see my responses inline.
> -----Original Message-----
> From: Ketan Talaulikar via Datatracker
> <nore...@ietf.org<mailto:nore...@ietf.org>>
> Sent: Thursday, April 10, 2025 1:07 AM
> To: The IESG <i...@ietf.org<mailto:i...@ietf.org>>
> Cc:
> draft-ietf-lsr-multi-...@ietf.org<mailto:draft-ietf-lsr-multi-...@ietf.org>;
> lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>;
> lsr@ietf.org<mailto:lsr@ietf.org>;
> yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>;
> yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>
> Subject: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: (with
> DISCUSS
> and COMMENT)
>
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-lsr-multi-tlv-14: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to the authors, first for taking up this work, and next for taking it
> through a "rigorous" WG process while focusing on technical aspects.
>
> However, there are still some aspects in the document that I would like to
> have
> a discussion on (inline using idnits output of v14):
>
> 152 This document specifies a means for extending TLVs where no
> extension
> 153 mechanism has been previously explicitly specified, and defines
> this
> 154 mechanism as the default extension mechanism for future TLVs. The
> 155 mechanism described in this document is applicable to top level
> TLVs
> 156 as well as any level of sub-TLVs which may appear within a top
> level
> 157 TLV.
>
> <discuss-1> Given that a TLV is bounded at 255 bytes, by definition its
> sub-TLVs (at first and subsequent levels) are bounded to an even smaller
> limit.
> This implies that if > 255 bytes need to be encoded in a 1st level sub-TLV,
> then we would need two parts of the parent TLV as well. While this is
> implicit, some text on this would be helpful - I would not be surprised if
> this gets missed by people working on future specifications. Taking it
> further,
> this aspect imposes some design restriction on the level of
> sub-TLV/sub-sub-TLV/... that can be designed for future extensions due to the
> reducing bounds as we go deeper. At some point, the overhead of the
> "process of breaking into parts" may start to bring in higher overheads than
> the actual information being conveyed. This brings in challenges in protocol
> encoding design (specifically with many layer of sub-TLVs). I would like to
> discuss why this document isn't providing such a guidance as well (or at least
> touching upon this aspect). Perhaps a recommendation would be to not go
> more
> than 2-3 level deep as there is a risk of hiting these limits?
>
[LES:] The scope of this document is quite intentionally limited to specifying
MP-TLV. It does not introduce any encoding changes or new limitations
to the protocol. Nesting level of sub-TLVs is a legitimate concern, but is
independent of MP-TLVs. Your comment about "overhead" is applicable to a
single TLV as well. I do not see that a discussion of this concern is
appropriate in this draft.
KT> The document does specify a mechanism on how TLV space is expanded and it
indicates the replication of the fixed and "keys" part at every
TLV/sub-TLV/sub-sub-TLV level (i.e., it takes away more space in doing so).
Therefore, as an extension, at least some text that touches upon its
implications for multiple nested TLV/sub-TLV usage is warranted in my view.
Such text will provide guidance to future developers working on ISIS extensions
and is something that can be quoted/pointed to. E.g., when some extension is
buried too deep in the TLV hierarchy, there may be a case to "pull it up" at
the top-level even if it might not be the best choice from a pure data model
perspective. Please consider this as an effort towards providing guidance to
new participants in a standards track ISIS document.
[LES2:] Hopefully I can say this without offending you…
IS-IS has always been frugal as regards the space used for encoding
information. This is because we have always been conscious both of the 255
octet TLV limit and the overall limit of LSP space.
You may recall examples of this in cases where some other protocol (e.g., BIER)
proposes an encoding for advertising information in the IGPs and uses the same
format for OSPF and IS-IS. We always insist this be revised for IS-IS.
Your major experience is with OSPF – and so you may think that the introduction
of MP-TLV would require extra diligence in this regard – but I am telling you
this is not the case.
As a WG member, I would not allow inefficient encoding to progress – completely
independent of any MP-TLV considerations. And I think you can examine the
output of IS-IS RFCs over that last 25 years as proof that the WG is already
diligent in this regard.
So your well intentioned concern is simply not appropriate.
> 289 For example, suppose that a router receives an LSP with a
> Multi-Part
> 290 Extended IS Reachability TLV. The first part contains key
> 291 information K with sub-TLVs A, B, and C. The second part contains
> 292 key information K with sub-TLVs D, E, and F. The receiving router
> 293 must then process this as having key information K and sub-TLVs A,
> B,
> 294 C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, E, F,
> A,
> 295 B, C, or any other permutation.
>
> <Discuss-2> What if there is a single instance sub-TLV within an MP-TLV? In
> this case, the ordering would be important if for some reason (or error) the
> sender were to send multiple copies of that single instance sub-TLV and the
> guidance is to 'use the first, ignore the rest'. Therefore, should the
> receiver
> not have to process based on the ordering in the LSP(s) and that the sender
> also is deliberate about the ordering of the parts in the LSP(s)?
>
> 310 Specifying how to handle such cases is the responsibility of the
> 311 document which defines the TLV. If such a document is not explicit
> 312 in how to handle such cases, it is RECOMMENDED that the first
> 313 occurrence in the lowest numbered LSP be used. In the case of
> IIHs,
> 314 it is RECOMMENDED that the first occurrence in the IIH be used.
>
[LES:] Order has never mattered in IS-IS. Whether an advertisement is present
in LSP #1 or LSP #200 has no impact on processing of that information.
Similarly, order of sub-TLVs within a TLV is of no significance.
The recommendation to use "the first occurrence in the lowest numbered LSP"
is addressing pathological/transient cases where information is duplicated.
It provides a deterministic resolution for such cases, but it does not
guarantee that the choice is "correct" i.e., that it is the latest information.
No rule will guarantee that in such cases.
KT> This isn't about correctness. It is about consistency across routers in the
network.
[LES2:] Well, you started this discuss asserting that:
“Therefore, should the receiver
not have to process based on the ordering in the LSP(s) and that the sender
also is deliberate about the ordering of the parts in the LSP(s)?...”
And I repeat that order does not matter.
Now you seem focused on trying to standardize behavior in the event of
duplicate/conflicting information.
Please be more precise in your comments.
As regards the use of RECOMMENDED in this paragraph, individual codepoints can
choose to specify a different deterministic method to handle
duplicate/conflicting information for that codepoint.
I am not suggesting that they should (quite the contrary) – but if they have
some reason to do so and they specify it clearly this is not an issue for the
protocol.
That is why we chose RECOMMEND here.
I stand by that choice.
> <Discuss-3> Why RECOMMENDED (as in SHOULD) and not a MUST to ensure
> we arrive
> at interoperable implementations down the line? Was there a proposal placed
> before the WG to make this a MUST and some objection received on it?
>
[LES:] We are not specifying normative behavior here - that is left to the
document which defines the codepoint. And there are existing examples of
different strategies
specified. This document is not the place for such normative statements.
KT> Well, the document is specifying normative behavior for those TLVs where
the respective spec is not already explicitly on this aspect. I am not getting
into the past. Neither should it be the responsibility of this document to try
to grandfather all the myriad ways in which things are being handled by
old/current implementations. The point is to move implementations forward
towards interoperability, and hence the MUST instead of SHOULD will help
achieve that goal in this regard. To me, this is in the same spirit as RFC8918.
[LES2:] RFC 8918 addressed a behavior that was clearly broken. That is not the
case here. Please do not use this analogy.
I believe my response above applies.
> 399 8. Deployment Considerations
>
> <Discuss-4> I would like to discuss why this document is not recommending
> that
> implementations and deployments move to RFC7356 as a long term approach
> to
> scaling IS-IS to carry more information. RFC7356 is referenced in the
> introduction, but some (short) additional text with references to its specific
> sections may be a helpful guide. I see that the authors (and some other WG
> members) had pointed to this work as "the long term solution", but the
> document has not captured that aspect.
>
[LES:] As an author of RFC 7356 I appreciate your interest. 😊
But this document is dealing with the current version of the protocol with its
current limitations. It is not a position paper on what the future of the
protocol should be.
KT> I disagree with your positioning of this document. There were more than one
proposal in front of the WG, and this particular one was picked for the 8-bit
TLV space encoding due to good reasons. It comes with its various challenges -
space, interoperability, etc. - so it is not perfect but pragmatic. At the same
time, during the WG discussion there were times when the topic of a long term
solution has come up (a few of the threads below) that concluded with pointing
to RFC7356 as a "clean" solution (albeit introducing in existing deployments is
challenging). So, I am wondering why the WG (not just the authors) would not
want to at least mention that RFC7356 provides the long term solution? I will
leave the recommendation part to the WG (though I personally strongly favor it).
https://mailarchive.ietf.org/arch/msg/lsr/rCHObOHT18sg61Dn60SJlvUWodU/
https://mailarchive.ietf.org/arch/msg/lsr/987n5mHQptaPpmc0EjnJ-p9yZGM/
[LES2:] Thanx for the email pointers – but they only reinforce my point.
Those emails were an attempt to separate the discussion of what we need to do
to address the 255 octet limit using the current version of the protocol from a
discussion of how a new /not backwards compatible version of the protocol would
address the issue.
My argument was – and continues to be – that is a separate topic – does not
belong in the MP-TLV specification.
RFC 7356 is mentioned in the draft – so that request from you is already met.
Further discussion of how RFC 7356 (or some other solution) would address the
issues is out of scope.
The draft is focused on what needs to be done with the current version of the
protocol.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please find below some comments provided inline in the idnit output of v14.
> Would appreciate a response and some clarifications on the same.
>
> 110 The original TLV definition limits each TLV to a maximum of 255
> 111 octets of payload, which is becoming increasingly stressful.
>
> <minor> How about the following?
>
> CURRENT
> The original TLV definition limits each TLV to a maximum of 255 octets of
> payload, which is becoming increasingly stressful.
>
> SUGGEST
> The original TLV definition limits each TLV to a maximum of 255 octets of
> payload are being increasingly stressed.
>
[LES:] I don't find your suggestion grammatically appealing. How about:
"The original TLV definition limits each TLV to a maximum of 255 octets of
payload, a limitation which is becoming increasingly problematic."
??
KT> Sounds good to me. I had trouble with "stressful" :-)
[LES2:] Done
> 113 Some TLV definitions have addressed this by explicitly stating
> that a
> 114 TLV may appear multiple times inside of a Link State PDU (LSP).
> 115 However, this has not been done for many legacy TLVs, leaving the
> 116 situation somewhat ambiguous.
>
> <minor> s/legacy/other - I am not sure the use of the term "legacy"
> is appropriate here since those TLVs are very much in use today and likely in
> the future as well.
>
[LES:] How about "for many currently defined TLVs"..."
KT> Ack
[LES2:] Done
> 147 The mechanism described in this document has not been documented
> for
> 148 all TLVs previously, so there is risk that interoperability
> problems
> 149 could occur. This document provides the necessary protocol
> 150 definition.
>
> <major> The above text is incomplete. I would suggest that this paragraph
> simply puts forward references to document sections that are dealing with
> interoperability challenges and backwards compatibility aspects.
>
[LES:] This text is in the "Introduction".
It therefore is expected that the text here is meant to introduce what follows.
The substance of the draft is - and is expected to be - in the subsequent
sections.
I do not understand your objection.
KT> A text suggestion to clarify my point:
The mechanism described in this document has not been documented for all TLVs
previously. The associated interoperability challenges are described in
Sections 7 and 8.
[LES2:] I have added some text – not quite as you suggested – but hopefully
meets your goal.
> 167 3. Overview of TLVs
>
> 169 A TLV is a tuple of (Type, Length, Value) and can be advertised in
> 170 IS-IS packets. Both Type and Length fields are one octet in size,
> 171 which leads to the limitation that a maximum of 255 octets can be
> 172 sent in a single TLV.
>
> <major> To do justice to the title of this section, why isn't it covering a
> single-instance TLV as well?
>
[LES:] It is discussing a single TLV instance.
MP-TLV is two or more related "single instance TLVs".
I am at a loss as to your concern.
KT> Let us consider the TLV for TE Default Metric. Which subsection of section
3 does it belong to? I am referring to covering non-MP TLVs since the section
title says "Overview of TLVs" (as in all types of ISIS TLVs).
[LES2:] OK – I think I missed your point. You are asking (I think) what about
TLVs to which MP-TLV does not apply?
I have revised the title of the section and added some text. Hopefully this
suffices.
> 247 The encoding of TLVs is not altered by the introduction of MP-TLV
> 248 support. In particular, the "key" which is used to identify the
> set
> 249 of TLVs which form an MP-TLV is the same key used in the absence of
> 250 MP-TLV support. Also note the definition of the "key" exists in
> the
> 251 specification(s) that define(s) the TLV.
>
> <minor> Perhaps
>
> CURRENT
> Also note the definition of the "key" exists in the specification(s) that
> define(s) the TLV.
>
> SUGGEST
> The definition of the "key" for a given TLV is outside the scope of this
> document and has to be part of the specification(s) that define(s) the TLV.
>
[LES:] I am OK with your revised text - except for the phrase "is outside the
scope". The point being made here is that definition already exists in other
documents.
"scope" is a non-issue.
KT> If there are no strong objections, I would prefer that this gets called out
of scope. It will help.
[LES2:] I revised the sentence in a way which makes me feel comfortable stating
“out of scope” – hopefully you are fine with this variant.
> 265 5. Procedure for Receiving Multi-Part TLVs
>
> 267 A router that receives a MP-TLV MUST accept all of the information
> in
> 268 all of the parts. The order of arrival and placement of the TLV
> 269 parts in LSP fragments is irrelevant. Multiple TLV parts MAY occur
> 270 in a single LSP or parts MAY occur in different LSPs.
>
> 272 The placement of the TLV parts in an IIH is irrelevant.
>
> <major> Does "placement" here also cover "ordering"? Is the intention
> here that it is not required that all parts be encoded consequtively in an
> LSP (or across LSP fragments), and that no specific ordering is expected?
> Please
> also see my discussion point 2.
>
[LES:] Yes - it covers "ordering".
Rereading the text, that seems very clear to me.
I do not understand your confusion.
KT> My point is that ordering is relevant when dealing with non-MP sub-TLVs
spread across multiple parts of a MP-TLV. So, the receiver cannot just ignore
the ordering. If it does so, it will not be able to pick the "right" (e.g., the
first instance in the lowest number LSP) non-MP sub-TLV instance for
consistency across routers.
[LES2:] I still cannot understand your point. The statement as you write it is
incorrect. Order of sub-TLVs at a given level of hierarchy does not matter.
Perhaps a specific example of what is troubling you would help??
> 351 For example, if there are mutiple TLVs associated with the
> 352 advertisement of a neighbor and some routers do not use all of the
> 353 link attributes advertised, then constrained path calculations
> based
> 354 on those attributes are likely to produce inconsistent results and
> 355 produce forwarding loops or dropped traffic.
>
> <minor> More specifically, this is for a distributed constraints path
> calculation (as in FlexAlgo)? For P2P TE computations, this may not present a
> loop but yes results might be not what is desired.
>
[LES:] Sure. But this is only an example of problems which may occur,
not a comprehensive list of all possible problems - which could fill many pages.
KT> It is important to specify the scope as ISIS calculations. That would help
address this comment. The current text refers to "constrained path
calculations" which could be construed as covering something that a TE
controller does as well.
[LES2:] This seems to me to be another aspect of your belief that controllers
don’t have to understand MP-TLVs – which I think is misguided.
Controllers have to correctly parse all of the information advertised by IS-IS.
They may choose, based on local policy, to ignore some attributes – but if they
cannot correctly parse the information advertised then they are applying that
policy on incomplete or incorrect information.
> 365 Routers which support MP-TLV for codepoints for which existing
> 366 specifications do not explicitly define such support, but for which
> 367 MP-TLV is applicable, SHOULD include this sub-TLV in a Router
> 368 Capability TLV.
>
> <major> Why is this not a MUST even if it is for informational purposes?
> Likely someone is relying on this information to be accurate. Please also see
> the next comment.
>
[LES:] This has been answered previously.
Here is my earlier reply to Eric:
<snip>
1)There are existing implementations which support MP-TLV for some codepoints -
requiring this advertisement would introduce backwards compatibility issues
2)Given that this sub-TLV is for informational purposes only, requiring it to
be sent seems inappropriate. Implementations which want to be helpful to
operators will likely choose to send it, but if they do not claiming that such
an implementation is non-conformant serves no useful purpose.
<end snip>
KT> I am with Eric on this. The purpose of this document should not be to
grandfather existing implementation choices that were made in the absence of
this spec. If some implementation is claiming compliance to this spec, then I
don't see why it cannot be mandated to advertise the capability as well. There
is no harm in adding text that there MAY be implementations which support
MP-TLV before this specification but do not advertise the capability. On the
second point, we should not preclude how this information is used by the
operator (or other systems) - the goal of ISIS
[LES2:] There is a fundamental disagreement here.
The advertisement says “This implementation might have MP-TLV support for a
codepoint you are interested in.”
As such, it is merely a hint to the operator.
Making this mandatory would mean that an implementation that actually has
MP-TLV support for a given codepoint would be considered unusable/non-compliant
simply because it did not advertise the sub-TLV which says “I have MP-TLV for
some codepoint.”
I do not agree to this.
> 373 This advertisement is for informational purposes only.
> 374 Implementations MUST NOT alter what is sent or how what is
> received
> 375 is processed based on these advertisements.
>
> <major> By implementations, I assume the reference here is to IS-IS protocol
> behavior? Because a controller should be free to use this information an adapt
> its behavior? Please clarify.
>
[LES:] I am not at all convinced that a controller is free to ignore portions
of an MP-TLV. Doing so risks the controller operating on faulty or
incomplete information. Nevertheless, I will change:
"Implementations" to "IS-IS protocol implementations"
KT> Thanks that change works.
[LES2:] Done
> 382 deployment scenarios in which it is used. Therefore, diligence is
> 383 still required on the part of the operator to ensure that
> 384 configurations which require the sending of MP-TLV for a given
> 385 codepoint are not introduced on any router in the network until all
> 386 routers in the network support MP-TLV for the relevant codepoints.
>
> <minor> Perhaps an informative reference here to the PICS YANG work would
> help?
>
[LES:] I prefer not to do this - though I understand your motivation.
The PICS work may well proceed slowly - or not proceed at all depending on
WG interest. That remains to be seen.
KT> I agree. However, following the WG discussions, I sense the interest from
operators in finding this information (in a management plane). And while it is
out of scope of this document, a pointer to that work will (optimistically)
generate interest in PICS work. More importantly, it conveys that the IETF has
not abandoned this operator requirement, just that it is solving it outside in
the management plane.
[LES2:] I have added a reference and some text.
> 401 Sending of MP-TLVs in the presence of routers that do not correctly
> 402 process such advertisements can result in interoperability issues,
> 403 including incorrect forwarding of packets. This section discusses
> 404 best practices which SHOULD be used when a deployment requires
> the
>
> <minor> Perhaps s/SHOULD/should since there isn't anything that is being
> specified in this sentence.
>
[LES:] As you may recall, the use of SHOULD here is a compromise. Some
WG members wanted a MUST, but the authors pushed back on this because
we felt strongly that it is not in the purview of an RFC to mandate
behaviors which are unenforceable and undetectable.
I would appreciate if you did not reopen this debate.
KT> Hmm ... I am suggesting changing SHOULD -> should (not talking about MUST
here ... that is further below).
[LES2:] I understand what you are asking for – but there was significant angst
because we chose not to use MUST.
SHOULD was a compromise.
“should” would require reopening that discussion.
Not a good use of our time IMO.
> 416 Network operators SHOULD NOT enable MP-TLVs until ensuring that
> all
> 417 implementations that will receive the MP-TLVs are capable of
> 418 interpreting them correctly as described in Section 5.
>
> <minor> The above sentence is better placed towards end of section 8.1 where
> those controls to enable/disable MP-TLVs are introduced.
>
[LES:] OK
[LES2:] Done
> 420 8.1. Recommended Controls and Alarms
>
> 422 It is RECOMMENDED that implementations which support the sending
> of
>
> <major> Why not MUST instead of RECOMMENDED (i.e., SHOULD) for the
> global
> control knob? This would be the bare minimum control that is required for the
> operator?
>
[LES:] Once again, you are trying to reopen something which was debated
at considerable length previously. The authors feel strongly that it is not
within the purview of an RFC to mandate how implementations implement
configuration. It is also unenforceable. The choice to use RECOMMENDED was
intentionally made and we do not want to revisit this choice.
KT> This is only about a global control for MP-TLV (not the TLV specific one)
that we are talking about. You are of course correct that IETF cannot enforce
the choices that implementations make. However, there is always a balance to
strike. In this case, in my view, the global control knob is something that can
be made a MUST. Again, there is no requirement on this document having to
grandfather everything that implementations are doing currently, but to set an
appropriate future direction.
[LES2:] We are not in agreement. Don’t have much new to say.
> 423 MP-TLVs provide configuration controls to enable/disable generation
> 424 of MP-TLVs. Given that MP-TLV support in a given implementation
> may
> 425 vary on a per TLV basis, these controls SHOULD support per
> codepoint
> 426 granularity.
>
> 444 Sending a single TLV with all the information about an object is
> 445 preferable to sending multiple TLVs. It is simpler and more
> 446 efficient to parse information from a single TLV than to combine
> the
> 447 information from multiple TLVs. Implementations SHOULD NOT send
> 448 multiple TLVs unless MP-TLV is applicable to the TLV and the amount
> 449 of information which is required to be sent exceeds the capacity
> of a
> 450 single TLV. For example, when additional space is required in an
> 451 existing TLV, as long as there is space in the TLV, information
> 452 SHOULD NOT be split into multiple TLVs. If there is no space in
> the
> 453 current LSP to fit the now larger TLV, the TLV SHOULD be moved to a
> 454 new LSP.
>
> <major> All of these are SHOULD instead of MUST. What would be the
> conditions
> in which they cannot be followed by implementations? Please consider adding
> some short explanatory text.
>
[LES:] This also was discussed at length in the WG.
The maxim of "be strict in what you send but generous in what you receive" is
being applied here.
We are describing the most efficient way to encode MP-TLVs and indicating
implementations SHOULD follow this behavior.
If the information is encoded correctly - but just packed sub-optimally -
it is not a benefit to network operation to have receivers ignore it -
which would be required in order for MUST to be appropriate.
It also could lead to some petty debates as to what is optimally packed
and what isn't.
KT> OK. Thanks. I caught up on that thread in the WG and I am good with what is
in the document currently.
Thanks,
Ketan
> 531 | 19 | IS-IS Flooding Request TLV | N |
> 532 +-----------+----------------------------------------+----+
> 533 | 20 | Area Proxy | N |
>
> <major> This has sub-TLVs and its own sub-TLV registry that is missing.
>
[LES:] OK - thanx for catching this.
[LES2:] Done
> 534 +-----------+----------------------------------------+----+
> 535 | 21 | Flooding Parameters TLV | N |
>
> <major> This has sub-TLVs and its own sub-TLV registry that is missing.
>
[LES:] OK - thanx for catching this.
[LES2:] Done
Les
> <EoR v14>
>
>
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
