[Lsr] I-D Action: draft-ietf-lsr-isis-ttz-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Topology-Transparent Zone Authors : Huaimo Chen Richard Li Yi Yang Anil Kumar S N Yanhe Fan Ning So Vic Liu Mehmet Toy Lei Liu Kiran Makhijani Filename: draft-ietf-lsr-isis-ttz-06.txt Pages : 26 Date: 2022-10-03 Abstract: This document specifies a topology-transparent zone in an IS-IS area. A zone is a subset (block/piece) of an area, which comprises a group of routers and a number of circuits connecting them. It is abstracted as a virtual entity such as a single virtual node or zone edges mesh. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-ttz-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-ttz-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
[As wg-member] --- inline... "Les Ginsberg (ginsberg)" writes: Chris - -Original Message- From: Christian Hopps Sent: Monday, October 3, 2022 8:37 AM To: Les Ginsberg (ginsberg) Cc: Robert Raszuk ; Tony Li ; Henk Smit ; lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt [As wg-member] I think the draft should include a table of all top level TLVS as rows and for columns we have - "Implicit Single TLV Only" (e.g., no key info) - "Implicit Multi-TLV Only" - "Explicit Single TLV Only" - "Explicit Multi-TLV-Allowed" This draft then would *explicitly* cover the existing "implicit" cases and we have the table to point at to be precise about what we are talking about. [LES:] I am not overly enthused about this - but I can see its usefulness, so I don’t oppose it. Probably best realized as an additional column in the existing IS-IS TLV Codepoints registry. But also realize that in some cases this extends to sub-TLVs (as one example "16 Application-Specific Link Attributes"). Now about the capability... There's an argument about including a router capability and it seems to be that people have agreed that it should *not* have any operation impact on the protocol. I think this is hasty. I would like to look at the above table to see what TLVs we are *exactly* talking about here (the implicit multi-tlv ones). People have said that implementations support multi-tlv use of these implicit cases (e.g., the draft talks about extended reachability). Really? [LES:] Yes - really. I could easily believe its not common. I think we should get specific about vendors and versions (and maybe specific TLVS?) if we are saying this has been deployed and is in use. I've written a few IS-IS implementations and I don't think *any* of them supported multiple tlvs of, for example, extended reachability (seeing 2 of the same keyed info would be seen as one replacing the other, or a bug if in the same LSP segment). [LES:] All of us who have "been around for a while" have worked on implementations that did not support MP-TLVs. Prior to new features (SR, TE Metric Extensions (RFC 8570), flex-algo, more extensive deployments of IPv6, etc.) there wasn't a need - at least for Neighbor/Prefix advertisements. But deployment requirements have evolved. We absolutely have cases today where a single TLV is insufficient space-wise for both neighbor and prefix advertisements and there are multiple implementations which already support this. If the WG wants to pursue an Implementation Report on this, I have no objection. BTW, the need for this should not surprise you. Discussion of this problem dates back at least to 2004: https://datatracker.ietf.org/doc /html/draft-shen-isis-extended-tlv-00 The need is not a surprise to me, no. Once we have this info I think a stronger case might be made for actually having the router capability be used *operationally* (i.e., if you don't see the capability advertised then that router in fact doesn't send multi-tlv tlvs and they should be seen as replacements of each other), and the argument about it's inclusion goes away as it's then required. [LES:] I don't agree with this argument - but I think the discussion triggered by posts from Gunter and Henk has already covered this well from both points of view, so I won’t repeat here. That discussion had to do with whether to include a bit that is for management purposes only. What I am seeing here is a need for an operationally relevant bit (i.e., determines how the protocol functions). AFAICT we now have implementations out there that are sending multiple TLVs which are not documented to be sent that way, that historically were not expected to be received that way, and then we have other implementations that do not expect this new, convenient but rather loose interpretation of the standards. Consider we have documents that explicitly state that a TLV can be sent multiple times, it would be completely normal for someone to then assume that when that isn't stated explicitly that multiple versions of those TLV will not be sent. Thus the need for this document -- in some form. Having all routers work from the same link-state database is basic requirement to the correct functioning of the decision process. Are we just lucky that things haven't really broken yet? How can an operator even know what they've got deployed? Before this document there's nothing to even refer to to document the possible different behaviors. If people want to argue that no operationally significant bit is needed then how can an operator be expected to get this right? What is the exact process they should follow to have interoperating routers? Thanks, Chris. [as wg-member] Les Thanks, Chris. [as wg-member] ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
Chris - > -Original Message- > From: Christian Hopps > Sent: Monday, October 3, 2022 8:37 AM > To: Les Ginsberg (ginsberg) > Cc: Robert Raszuk ; Tony Li ; Henk Smit > ; lsr@ietf.org > Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv- > 01.txt > > > [As wg-member] > > I think the draft should include a table of all top level TLVS as rows and for > columns we have > > - "Implicit Single TLV Only" (e.g., no key info) > - "Implicit Multi-TLV Only" > - "Explicit Single TLV Only" > - "Explicit Multi-TLV-Allowed" > > This draft then would *explicitly* cover the existing "implicit" cases and we > have the table to point at to be precise about what we are talking about. > [LES:] I am not overly enthused about this - but I can see its usefulness, so I don’t oppose it. Probably best realized as an additional column in the existing IS-IS TLV Codepoints registry. But also realize that in some cases this extends to sub-TLVs (as one example "16 Application-Specific Link Attributes"). > Now about the capability... There's an argument about including a router > capability and it seems to be that people have agreed that it should *not* > have any operation impact on the protocol. > > I think this is hasty. I would like to look at the above table to see what > TLVs > we are *exactly* talking about here (the implicit multi-tlv ones). People have > said that implementations support multi-tlv use of these implicit cases (e.g., > the draft talks about extended reachability). > > Really? [LES:] Yes - really. > > I could easily believe its not common. I think we should get specific about > vendors and versions (and maybe specific TLVS?) if we are saying this has > been deployed and is in use. I've written a few IS-IS implementations and I > don't think *any* of them supported multiple tlvs of, for example, extended > reachability (seeing 2 of the same keyed info would be seen as one replacing > the other, or a bug if in the same LSP segment). [LES:] All of us who have "been around for a while" have worked on implementations that did not support MP-TLVs. Prior to new features (SR, TE Metric Extensions (RFC 8570), flex-algo, more extensive deployments of IPv6, etc.) there wasn't a need - at least for Neighbor/Prefix advertisements. But deployment requirements have evolved. We absolutely have cases today where a single TLV is insufficient space-wise for both neighbor and prefix advertisements and there are multiple implementations which already support this. If the WG wants to pursue an Implementation Report on this, I have no objection. BTW, the need for this should not surprise you. Discussion of this problem dates back at least to 2004: https://datatracker.ietf.org/doc/html/draft-shen-isis-extended-tlv-00 > > Once we have this info I think a stronger case might be made for actually > having the router capability be used *operationally* (i.e., if you don't see > the > capability advertised then that router in fact doesn't send multi-tlv tlvs and > they should be seen as replacements of each other), and the argument > about it's inclusion goes away as it's then required. > [LES:] I don't agree with this argument - but I think the discussion triggered by posts from Gunter and Henk has already covered this well from both points of view, so I won’t repeat here. Les > Thanks, > Chris. > [as wg-member] ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-flex-algo-24: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-flex-algo-24: No Objection 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-flex-algo/ -- COMMENT: -- Thank you to Charlie Kaufman for the SECDIR review. ** Section 4. We want the mapping between the Flex-Algorithm and its meaning to be flexible and defined by the user. Is a “Flex-Algorithm” (with hyphen) the same as a “Flex Algorithm” (no hyphen) defined in Section 3? Why the difference in notation? ** Section 4. The set consisting of (a) calculation-type, (b) metric-type, and (c) a set of constraints is referred to as a Flexible-Algorithm Definition. Flexible-Algorithm is a numeric identifier in the range 128-255 that is associated via configuration with the Flexible-Algorithm Definition. This text repeats the text in Section 3 verbatim. Is it needed twice? ** Section 5. ... and (b) are in the same Flex-Algorithm definition advertisement scope What is a “FAD advertisement scope?” Should this be an additional term defined in Section 3? ** Section 5.1. Should the explanation of “Metric-Type” say that it’s value comes from the “IGP Metric-Type Registry” per Section 18.1.2? Section 5.1. Is it possible for a peer not to support a particular Metric-Type? If so, have is that signaled? ** Section 5.1. An IS-IS L1/L2 router MAY be configured to re-generate the winning FAD from level 2, ... What is the “winning FAD?” ** Section 5.1 and 5.2. Editorial. Definition of Flex-Algorithm in the TLV. -- Section 5.1 Flex-Algorithm: Single octet value between 128 and 255 inclusive. -- Section 5.2 Flex-Algorithm:: Flex-Algorithm number. Value between 128 and 255 inclusive. Should this text be the same? ** Section 5.2. Editorial. Why is the text defining Metric-Type repeated verbatim from what is written in Section 5.1, but Calc-Type and Priority cite Section 5.1? ** Section 6.4. New flag bits may be defined in the future. Implementations MUST check all advertised flag bits in the received IS-IS FADF Sub-TLV - not just the subset currently defined. Let’s assume bits other than those define in this document are set. Is there an IANA registry to check to understand their semantics? ** Section 13.1. During the route computation, it is possible for the Flex-Algorithm specific metric to exceed the maximum value that can be stored in an unsigned 32-bit variable. In such scenarios, the value MUST be considered to be of value 0x during the computation and advertised as such. Should this guidance be referenced in Section 8 – that 0x could be 0x or an overflow value? ** Section 17. This draft adds two new ways to disrupt IGP networks: An attacker can hijack a particular Flex-Algorithm by advertising a FAD with a priority of 255 (or any priority higher than that of the legitimate nodes). An attacker could make it look like a router supports a particular Flex-Algorithm when it actually doesn't, or vice versa. What are the consequences of the described attacker behaviors? Is “disrupt[ing] the IGP networks” just a denial of service? Could it also be steering traffic in a particular way to allow inspection or modification; or to avoid network based mitigations? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-ospf-bfd-strict-mode-08: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-ospf-bfd-strict-mode-08: No Objection 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-ospf-bfd-strict-mode/ -- COMMENT: -- Thank you to Wes Hardaker for the SECDIR review. ** Section 1. Typo. s/adjaceny/adjacency/ ** Section 1. Typo. s/establishement/establishment/ ** Section 8. If authentication is being used in the OSPF routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV [RFC5613] SHOULD also be used to protect the contents of the LLS block. Since strict-mode BFD functionality is not going to be present in legacy implementations, could it be mandatory to protect the LLS block (i.e., use of the Cryptographic Authentication TLV is a MUST)? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Secdir last call review of draft-ietf-lsr-isis-flood-reflection-10
Reviewer: Rich Salz Review result: Has Nits I am a routing naïf and do not have a lot of time these days. I hope this review is still useful, anyway. The glossary was very helpful. I still don't have a clear understanding of L1 and L2. The picture is a tour de force. The description "Figure 1 is an example..." paragraph should be moved before the picture, not directly after it. Sections 6 and 7 indicate, to me, that this document is comprehensive and informed by real-world concerns. Sec 9, Security Considerations. This is where I did the most careful reading. "If an attacker should be able..." s/should be able/can/ s/could be in most extreme case/could be in THE most extreme case/ It was a bit surprising to me to see the same sentence at the end of both paragraph 1 and paragraph 2. Maybe remove them and move them to the start of paragraph 3. I think the risks are well-described, and the importance to preventing is made. Is it possible to mitigate the damage if a risk occurs? "No" is a reasonable answer. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
[As wg-member] I think the draft should include a table of all top level TLVS as rows and for columns we have - "Implicit Single TLV Only" (e.g., no key info) - "Implicit Multi-TLV Only" - "Explicit Single TLV Only" - "Explicit Multi-TLV-Allowed" This draft then would *explicitly* cover the existing "implicit" cases and we have the table to point at to be precise about what we are talking about. Now about the capability... There's an argument about including a router capability and it seems to be that people have agreed that it should *not* have any operation impact on the protocol. I think this is hasty. I would like to look at the above table to see what TLVs we are *exactly* talking about here (the implicit multi-tlv ones). People have said that implementations support multi-tlv use of these implicit cases (e.g., the draft talks about extended reachability). Really? I could easily believe its not common. I think we should get specific about vendors and versions (and maybe specific TLVS?) if we are saying this has been deployed and is in use. I've written a few IS-IS implementations and I don't think *any* of them supported multiple tlvs of, for example, extended reachability (seeing 2 of the same keyed info would be seen as one replacing the other, or a bug if in the same LSP segment). Once we have this info I think a stronger case might be made for actually having the router capability be used *operationally* (i.e., if you don't see the capability advertised then that router in fact doesn't send multi-tlv tlvs and they should be seen as replacements of each other), and the argument about it's inclusion goes away as it's then required. Thanks, Chris. [as wg-member] signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Opsdir last call review of draft-ietf-lsr-flex-algo-23
Hi Linda, the version 24 includes the new section about the number of flex-algos as you requested. thanks, Peter On 22/09/2022 16:53, Linda Dunbar wrote: Peter, Thank you! I've studied this draft in LSR WG multiple times. I had a difficult time thinking how a router computing the paths when receiving 100+ topologies for one IGP domain, until being told most deployments only having handful of topologies. Linda -Original Message- From: Peter Psenak Sent: Thursday, September 22, 2022 2:57 AM To: Linda Dunbar ; ops-...@ietf.org Cc: draft-ietf-lsr-flex-algo@ietf.org; last-c...@ietf.org; lsr@ietf.org Subject: Re: Opsdir last call review of draft-ietf-lsr-flex-algo-23 Hi Linda, On 22/09/2022 00:24, Linda Dunbar via Datatracker wrote: Reviewer: Linda Dunbar Review result: Has Nits I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies a set of extensions to IGP to enable multiple topologies within one IGP domain, and each topology has its unique constraint-based path computation metric. It would be very helpful if Section 15 (Operational Consideration) included some considerations on the number of topologies to be created for exemplary deployments. Even though theoretically, hundreds/thousands of topologies can be supported by the mechanisms described in the draft, in practice, probably only a handful of (or even fewer) Flex-Algorithms are needed per IGP domain. It would be so much easier to follow the document if knowing only two or three Flex-Algorithm are needed. the maximum number of flex-algos is determined by the algorithm range that is (128-255), as specified in section 4 of the draft: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-23%23section-4data=05%7C01%7Clinda.dunbar%40futurewei.com%7C1f01cedc0b8b47ea277808da9c6fff8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637994302096955841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tZyj49cl6PorH91QIoebPQ8PcTTWKGNJwDaCIel2GEE%3Dreserved=0 I can add a sentence in the draft saying that the expected deployment is to use only a subset of those. thanks, Peter Thank you Linda Dunbar ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Lars Eggert's No Objection on draft-ietf-lsr-flex-algo-23: (with COMMENT)
Hi Lars, thanks for your comments, I incorporated then in the version 24 that has just been published. thanks, Peter On 30/09/2022 14:05, Lars Eggert via Datatracker wrote: Lars Eggert has entered the following ballot position for draft-ietf-lsr-flex-algo-23: No Objection 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-flex-algo/ -- COMMENT: -- # GEN AD review of draft-ietf-lsr-flex-algo-23 CC @larseggert Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/ttCI9O3hhN2Ryyic_0GWCj-ZDMY). ## Comments ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `traditionally`; alternatives might be `classic`, `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, `long-established`, `popular`, `prescribed`, `regular`, `rooted`, `time-honored`, `universal`, `widely used`, `widespread` * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`, `intrinsic`, `original` ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos Section 4, paragraph 4 ``` -is associated via configuratin with the Flexible-Algorithm +is associated via configuration with the Flexible-Algorithm + + ``` Section 5.3, paragraph 9 ``` -A router that is not participating in a particular Flex-Algorithm is - ^^ -allowed to advertise FAD for such Flex-Algorithm. Receiving routers - --- +A router that is not participating in a particular Flex-Algorithm MAY + ^^^ ``` Section 6, paragraph 1 ``` -FAD may be split into multiple such sub-TLVs and the content of the -^^^ +FAD MAY be split into multiple such sub-TLVs and the content of the +^^^ ``` Section 6.4, paragraph 10 ``` -Bits that are NOT transmitted MUST be treated as if they are set to 0 - ^^^ +Bits that are not transmitted MUST be treated as if they are set to 0 + ^^^ ``` Section 6.4, paragraph 13 ``` -TLV, all the bits are assumed to be set to 0. +TLV, all the bits MUST be treated as set to 0. ``` Section 7.4, paragraph 10 ``` -Bits that are NOT transmitted MUST be treated as if they are set to 0 - ^^^ +Bits that are not transmitted MUST be treated as if they are set to 0 + ^^^ ``` Section 7.4, paragraph 12 ``` -the bits are assumed to be set to 0. +the bits MUST be treated as set to 0. ``` Section 9, paragraph 17 ``` - Reserved: Must be set to 0, ignored at reception. - ^^^ + Reserved: MUST be set to 0, ignored at reception. + ^^^ ``` Section 10.2, paragraph 11 ``` - Reserved: Three octets. Must be set to 0, ignored at reception. - ^^^ + Reserved: Three octets. MUST be set to 0, ignored at reception. + ^^^ ``` Section 12, paragraph 2 ``` -then legacy advertisements are to be used, subject to the procedures - ^^ +then legacy advertisements MUST be used, subject to the procedures + ``` Section 13.1, paragraph 1 ``` -Algorithm in the next area or domain, the traffic may be dropped by - ^^^ +Algorithm in the next area or domain, the traffic MAY be dropped by + ^^^ ``` Section 13.1, paragraph 13 ``` -considered to be of value 4,294,967,295 during the computation and - ^ +considered to be of value 0x during the computation and + ^^ ``` Section 14.1, paragraph 4 ``` -paths, MUST be dropped
[Lsr] I-D Action: draft-ietf-lsr-flex-algo-24.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IGP Flexible Algorithm Authors : Peter Psenak Shraddha Hegde Clarence Filsfils Ketan Talaulikar Arkadiy Gulko Filename: draft-ietf-lsr-flex-algo-24.txt Pages : 49 Date: 2022-10-03 Abstract: IGP protocols historically compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-24 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-ospf-l2bundles-06: (with DISCUSS and COMMENT)
Hi, On 2022-9-30, at 16:37, Ketan Talaulikar wrote: > In brief, the proposal was to introduce the following text in the IANA > considerations: > > >This document updates the guidance to IANA for further allocations >from the "OSPFv2 Extended Link TLV Sub-TLVs" [1] and the >"OSPFv3 Extended LSA Sub-TLVs" [2] registries and requests the addition >of this document as a reference to those registries. It requires >that any document requesting allocation of code point from these >two registries need to indicate the applicability of the introduced >sub-TLV to the L2 Bundle Member TLV in that document. something along those lines would work for me. Thanks, Lars signature.asc Description: Message signed with OpenPGP ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
