Re: [Lsr] Request WG adoption of TTZ
Hi Huaimo, > 1). It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ > abstracts a zone to a single node. This abstraction is supported by the > extensions to IS-IS, and some of these extensions are not defined in Area > Proxy. For example, the extensions for the edge nodes of the zone are not > defined in Area Proxy. > > The details is underlined above. It says that some of the extensions in > IS-IS TTZ are not defined in Area Proxy. It seems accurate if we look at the > details Apparently, we have very different understandings of the words “amended to”. And so it goes. Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request WG adoption of TTZ
Hi Tony， 1). It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ abstracts a zone to a single node. This abstraction is supported by the extensions to IS-IS, and some of these extensions are not defined in Area Proxy. For example, the extensions for the edge nodes of the zone are not defined in Area Proxy. The details is underlined above. It says that some of the extensions in IS-IS TTZ are not defined in Area Proxy. It seems accurate if we look at the details. Best Regards, Huaimo From: Tony Li Sent: Tuesday, July 14, 2020 12:20 AM To: Huaimo Chen Cc: lsr@ietf.org ; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ Hi Huaimo, 1). It seems that Area Proxy can not be amended to IS-IS TTZ. I feel that this is somewhat imprecise. >From my perspective, our attempts to collaborate have been hampered by >governmental regulations that are wholly out of our control. The suggestions >that I’ve made for continued collaboration within the bounds of those controls >have not been well received. Thus, to say that something cannot be done is >overstating the case. We have simply not been wiilling to do so, which is >most unfortunate. Who can say what could happen if we could find a way for >all three proposals to collaborate? Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request WG adoption of TTZ
Hi Huaimo, > 1). It seems that Area Proxy can not be amended to IS-IS TTZ. I feel that this is somewhat imprecise. From my perspective, our attempts to collaborate have been hampered by governmental regulations that are wholly out of our control. The suggestions that I’ve made for continued collaboration within the bounds of those controls have not been well received. Thus, to say that something cannot be done is overstating the case. We have simply not been wiilling to do so, which is most unfortunate. Who can say what could happen if we could find a way for all three proposals to collaborate? Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Hi Les, Looks good, thanks for making these tweaks. (I was about to write "hopefully final" but I see that half the IESG still has to weigh in ... so I can't really expect this to be the last word quite yet.) -Ben On Tue, Jul 14, 2020 at 03:39:55AM +, Les Ginsberg (ginsberg) wrote: > Ben - > > I have prepared V3 of the draft to address your comments. > As the window for draft submissions is temporarily closed, I have attached > the diffs for your review. > > I will post the updated version once the window for submissions reopens. > > A few more remarks inline. > > > -Original Message- > > From: Benjamin Kaduk > > Sent: Monday, July 13, 2020 4:24 PM > > To: Les Ginsberg (ginsberg) > > Cc: The IESG ; draft-ietf-lsr-isis-invalid-...@ietf.org; lsr- > > cha...@ietf.org; lsr@ietf.org; Christian Hopps ; > > aretana.i...@gmail.com > > Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: > > (with > > COMMENT) > > > > Hi Les, > > > > On Mon, Jul 13, 2020 at 11:05:35PM +, Les Ginsberg (ginsberg) wrote: > > > Ben - > > > > > > > > > > > > Thanx for your review. > > > > My pleasure; this is a nice document. (A shame it's needed, of course, but > > that's neither here nor there.) > > > > > Responses inline. > > > > > > > > > > > > > -Original Message- > > > > > > > From: Benjamin Kaduk via Datatracker > > > > > > > Sent: Monday, July 13, 2020 2:11 PM > > > > > > > To: The IESG > > > > > > > Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; > > > > lsr@ietf.org; > > > > > > > Christian Hopps ; aretana.i...@gmail.com; > > > > > > > cho...@chopps.org > > > > > > > Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: > > > > (with > > > > > > > COMMENT) > > > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > > > draft-ietf-lsr-isis-invalid-tlv-02: Yes > > > > > > > > > > > > > > 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/iesg/statement/discuss- > > criteria.html > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > COMMENT: > > > > > > > -- > > > > > > > > > > > > > > The shepherd writeup is a bit unclear as to why Proposed Standard is the > > > > > > > right document status (vs., e.g., Informational). I guess it's desired > > > > > > > to have the Updates: relationship to the indicated documents, which > > > > > > > essentially forces it to be standards-track. On the other hand, perhaps > > > > > > > the sense that ignoring a TLV that is specifically disallowed (as > > > > > > > opposed to "merely" unrecognized) is itself a newly specified > > > > > > > requirement, in which case the status as Proposed Standard makes sense > > > > > > > for that reason. It might be worth a little more clarity on which (if > > > > > > > either) of these scenarios are intended. > > > > > > > > > > > > > [Les:] What prompted the writing of this document was a real world > > interoperability scenario wherein one implementation generated a > > malformed TLV and a receiving implementation rejected the entire PDU > > because of it. This resulted in persistent LSPDB inconsistency in the > > network > > for a prolonged period with a significant impact on the proper functioning > > of > > the network. This failure was considered significant enough that Standards > > Track seemed appropriate. > > > > > > > > > > > > As the document developed, the authors were encouraged to address > > some other issues, one of which was clarifying disallowed TLV handling as > > well. > > > > > > > > > > > > I can understand why Informational track may seem appropriate to you. In > > early discussions with Alvaro I had suggested that there was no need to > > write > > the document - that existing specifications were sufficiently clear. But the > > fact that - despite existing standards - such an interoperability issue did > > occur > > was compelling. The WG also embraced this as useful. > > > > Thanks for the extra explanation. I think PS makes sense, and the only > > text change I might (emphasis: *might*) consider is to emphasize that the > > "occurrence of non-conformant behavior seen in real world deployments" is > > decidedly not hypothetical. But I could understand if the current text is > > seen to be saying that already, too. > > > [Les:] There is mention in
Re: [Lsr] Request WG adoption of TTZ
I support the adoption of IS-IS TTZ draft. 1). It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ abstracts a zone to a single node. This abstraction is supported by the extensions to IS-IS, and some of these extensions are not defined in Area Proxy. For example, the extensions for the edge nodes of the zone are not defined in Area Proxy. 2). IS-IS TTZ abstracts a zone to a single node. A zone is any target block or piece of an IS-IS area, which is to be abstracted. This seems more flexible and convenient to users. 3). IS-IS TTZ provides smooth transferring between a zone and its single virtual node. That is that a zone can be smoothly transferred to a single virtual node, and the virtual node can be smoothly rolled back to the zone. This should improve customer experience since converting any block of an area to a single node is smooth with minimum or no service interruption. 4). Using IS-IS TTZ for network scalability may reduce the users' workload or make their work easier. They may put less efforts on planning a zone to be abstracted to a node. After the zone is abstracted to a node, the node can be rolled back to the zone smoothly if they want to redefine the zone. BTW, RFC 8099 (OSPF TTZ) is for abstracting a zone of an OSPF area to its edges full mesh. IS-IS TTZ is much better than RFC 8099 regarding to improving network scalability since IS-IS TTZ focuses on abstracting a zone to a single node. Best Regards, Huaimo From: Kiran Makhijani Sent: Monday, July 13, 2020 3:36 PM To: Yanhe Fan ; Donald Eastlake ; Huaimo Chen Cc: lsr@ietf.org ; lsr-cha...@ietf.org Subject: RE: [Lsr] Request WG adoption of TTZ I support IS-IS TTZ adoption for its value in reducing LSDB through abstraction. -Kiran -Original Message- From: Lsr On Behalf Of Yanhe Fan Sent: Sunday, July 12, 2020 7:33 AM To: Donald Eastlake ; Huaimo Chen Cc: lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ I support adaption of this IS-IS TTZ draft. It is a useful work to address network scalability. Thanks, Yanhe -Original Message- From: Lsr On Behalf Of Donald Eastlake Sent: Friday, July 10, 2020 1:08 PM To: Huaimo Chen Cc: lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ I support adoption of the IS-IS TTZ draft. It seems more flexible and capable although some editorial/nomenclature improvements in the draft would be good. I will send some more detailed suggestions to the authors. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen wrote: > > Hi Chris and Acee, and everyone, > > > > I would like to request working group adoption of "Topology-Transparent > Zone" > > (TTZ for short) > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399sdata=A4bYj%2B6ViMLIBApX1qQj93306nRIyL4aKs5QR0t%2B%2FJg%3Dreserved=0 > . > > > This draft comprises the following solutions for helping to improve > scalability: > > 1) abstracting a zone to a single pseudo node in IS-IS, > > 2) abstracting a zone to a single pseudo node in OSPF, > > 3) abstracting a zone to zone edges' full mess in IS-IS, and > > 4) transferring smoothly between a zone and a single pseudo node. > > A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone > or > > non-backbone area). > > > > When a network area becomes (too) big, we can reduce its size in > the sense > > of its LSDB size through abstracting a zone to a single pseudo node or > > abstracting a few zones to a few pseudo nodes. > > > > While a zone is being abstracted (or transferred) to a single > pseudo node, > > the network is stable. There is no or minimum service interruption. > > > > After abstracting a few zones to a few pseudo nodes, if we want to > reconstruct > > them, we can transfer (or roll) any of the pseudo nodes back to its > zone smoothly > > with no or minimum service interruption. > > > > We had a prototype implementation of abstracting a zone to zone > edges' full > > mess in OSPF. The procedures and related protocol extensions for > transferring > > smoothly from a zone to zone edges' full mess are implemented and tested. > > A zone (block of an OSPF area) is smoothly transferred to its edges’ > full mess > > without any routing disruptions. The routes on every router are stable > while > > the zone is being transferred to its edges' mess. It is very easy to > operate > > the transferring. > > > > There are two other drafts for improving scalability: "Area Proxy for > IS-IS" > > (Area Proxy for short) and "IS-IS Flood
Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Roman (and Acee) - After a suggestion from Ben, I have reworded the sentence to read: " When new protocol behaviors are specified that are not backwards compatible, it is RECOMMENDED that implementations provide controls for their enablement. This serves to prevent interoperability issues and allow for non-disruptive introduction of the new functionality into an existing network." Let me know if this resolves the concerns. Les > -Original Message- > From: Acee Lindem (acee) > Sent: Monday, July 13, 2020 9:38 AM > To: Les Ginsberg (ginsberg) ; Roman Danyliw > ; The IESG > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft- > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Roman Danyliw's No Objection on > draft-ietf-lsr-isis-invalid- > tlv-02: (with COMMENT) > > > > On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" > wrote: > > Acee - > > Inline. > > > -Original Message- > > From: Acee Lindem (acee) > > Sent: Monday, July 13, 2020 9:04 AM > > To: Les Ginsberg (ginsberg) ; Roman Danyliw > > ; The IESG > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; > draft- > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > > Subject: Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis- > invalid- > > tlv-02: (with COMMENT) > > > > Hi Les, > > > > On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" > > wrote: > > > > Roman - > > > > Thanx for the review. > > Inline. > > > > > -Original Message- > > > From: Lsr On Behalf Of Roman Danyliw via > > > Datatracker > > > Sent: Monday, July 13, 2020 7:40 AM > > > To: The IESG > > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; > cho...@chopps.org; > > draft- > > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > > > Subject: [Lsr] Roman Danyliw's No Objection on > draft-ietf-lsr-isis- > invalid- > > tlv- > > > 02: (with COMMENT) > > > > > > Roman Danyliw has entered the following ballot position for > > > draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss- > > criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found > here: > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > > > > > > > > > > -- > > > COMMENT: > > > > -- > > > > > > I'm glad to see language clarifying error handling. Thanks for > the work > on > > it. > > > > > > Section 3.2. Per “It is RECOMMENDED that implementations provide > > controls > > > for > > > the enablement of behaviors that are not backward compatible”, I > want > > to > > > double > > > check that I’m understanding this sentence correctly. RFC5304 > provides > > > normative guidance that isn’t backward compatible with ISO10589. > > RFC6233 > > > provide guidance that isn’t backward compatible with either > RFC5304 > or > > > ISO10589. Is the initial sentence effectively saying that > implementations > > > should support deployments in configurations that are not backward > > > compatible > > > (i.e., those using the newer TLVs)? As these changes are covering > > security > > > matters, I read “controls” in the cyber mitigation sense -- they > prevent an > > > action, not enable one. > > > > [Les:] The recommendation is for implementations to provide control > as to > > when the new (non-backwards compatible) behavior is used. > > Without that, an implementation which adds support for (to use one > > example) sending the Purge Originator TLV in the presence of MD5 > > authentication would simply start sending it and risk the PDU not being > > accepted by implementations which had not yet added the support. > > > > One way of reading this is that "including the POI TLV in purges w > MD5 > > authentication" is "enablement" of a new feature. Another way of > reading it > > might be "disablement" of the use of a new feature. > > This seems to me to be a semantical distinction. > > > > The
Re: [Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Ben - I have prepared V3 of the draft to address your comments. As the window for draft submissions is temporarily closed, I have attached the diffs for your review. I will post the updated version once the window for submissions reopens. A few more remarks inline. > -Original Message- > From: Benjamin Kaduk > Sent: Monday, July 13, 2020 4:24 PM > To: Les Ginsberg (ginsberg) > Cc: The IESG ; draft-ietf-lsr-isis-invalid-...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org; Christian Hopps ; > aretana.i...@gmail.com > Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with > COMMENT) > > Hi Les, > > On Mon, Jul 13, 2020 at 11:05:35PM +, Les Ginsberg (ginsberg) wrote: > > Ben - > > > > > > > > Thanx for your review. > > My pleasure; this is a nice document. (A shame it's needed, of course, but > that's neither here nor there.) > > > Responses inline. > > > > > > > > > -Original Message- > > > > > From: Benjamin Kaduk via Datatracker > > > > > Sent: Monday, July 13, 2020 2:11 PM > > > > > To: The IESG > > > > > Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; > > > lsr@ietf.org; > > > > > Christian Hopps ; aretana.i...@gmail.com; > > > > > cho...@chopps.org > > > > > Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with > > > > > COMMENT) > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-lsr-isis-invalid-tlv-02: Yes > > > > > > > > > > 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/iesg/statement/discuss- > criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > > > > > > > > > > > > > > > > > -- > > > > > COMMENT: > > > > > -- > > > > > > > > > > The shepherd writeup is a bit unclear as to why Proposed Standard is the > > > > > right document status (vs., e.g., Informational). I guess it's desired > > > > > to have the Updates: relationship to the indicated documents, which > > > > > essentially forces it to be standards-track. On the other hand, perhaps > > > > > the sense that ignoring a TLV that is specifically disallowed (as > > > > > opposed to "merely" unrecognized) is itself a newly specified > > > > > requirement, in which case the status as Proposed Standard makes sense > > > > > for that reason. It might be worth a little more clarity on which (if > > > > > either) of these scenarios are intended. > > > > > > > > > [Les:] What prompted the writing of this document was a real world > interoperability scenario wherein one implementation generated a > malformed TLV and a receiving implementation rejected the entire PDU > because of it. This resulted in persistent LSPDB inconsistency in the network > for a prolonged period with a significant impact on the proper functioning of > the network. This failure was considered significant enough that Standards > Track seemed appropriate. > > > > > > > > As the document developed, the authors were encouraged to address > some other issues, one of which was clarifying disallowed TLV handling as > well. > > > > > > > > I can understand why Informational track may seem appropriate to you. In > early discussions with Alvaro I had suggested that there was no need to write > the document - that existing specifications were sufficiently clear. But the > fact that - despite existing standards - such an interoperability issue did > occur > was compelling. The WG also embraced this as useful. > > Thanks for the extra explanation. I think PS makes sense, and the only > text change I might (emphasis: *might*) consider is to emphasize that the > "occurrence of non-conformant behavior seen in real world deployments" is > decidedly not hypothetical. But I could understand if the current text is > seen to be saying that already, too. > [Les:] There is mention in the Abstract that " deployment experience has shown..." > > > > > > > Section 1 > > > > > > > > > >A corollary to ignoring unknown TLVs is having the validation of PDUs > > > > >be independent from the validation of the TLVs contained in the PDU. > > > > > > > > > > nit: this doesn't exactly seem like a "corollary" specifically, but > > > > > rather a choice that [ISO10589] made (and which keeps some overall > sense > > > > > of consistency between PDU and TLV handling). > > > > > > > > > [Les:] Rejecting a PDU because of some issue with a single TLV would mean > that the full set of updates contained
Re: [Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Hi Les, On Mon, Jul 13, 2020 at 11:05:35PM +, Les Ginsberg (ginsberg) wrote: > Ben - > > > > Thanx for your review. My pleasure; this is a nice document. (A shame it's needed, of course, but that's neither here nor there.) > Responses inline. > > > > > -Original Message- > > > From: Benjamin Kaduk via Datatracker > > > Sent: Monday, July 13, 2020 2:11 PM > > > To: The IESG > > > Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; > > lsr@ietf.org; > > > Christian Hopps ; aretana.i...@gmail.com; > > > cho...@chopps.org > > > Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with > > > COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-lsr-isis-invalid-tlv-02: Yes > > > > > > 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/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > > > > > > > > > -- > > > COMMENT: > > > -- > > > > > > The shepherd writeup is a bit unclear as to why Proposed Standard is the > > > right document status (vs., e.g., Informational). I guess it's desired > > > to have the Updates: relationship to the indicated documents, which > > > essentially forces it to be standards-track. On the other hand, perhaps > > > the sense that ignoring a TLV that is specifically disallowed (as > > > opposed to "merely" unrecognized) is itself a newly specified > > > requirement, in which case the status as Proposed Standard makes sense > > > for that reason. It might be worth a little more clarity on which (if > > > either) of these scenarios are intended. > > > > > [Les:] What prompted the writing of this document was a real world > interoperability scenario wherein one implementation generated a malformed > TLV and a receiving implementation rejected the entire PDU because of it. > This resulted in persistent LSPDB inconsistency in the network for a > prolonged period with a significant impact on the proper functioning of the > network. This failure was considered significant enough that Standards Track > seemed appropriate. > > > > As the document developed, the authors were encouraged to address some other > issues, one of which was clarifying disallowed TLV handling as well. > > > > I can understand why Informational track may seem appropriate to you. In > early discussions with Alvaro I had suggested that there was no need to write > the document - that existing specifications were sufficiently clear. But the > fact that - despite existing standards - such an interoperability issue did > occur was compelling. The WG also embraced this as useful. Thanks for the extra explanation. I think PS makes sense, and the only text change I might (emphasis: *might*) consider is to emphasize that the "occurrence of non-conformant behavior seen in real world deployments" is decidedly not hypothetical. But I could understand if the current text is seen to be saying that already, too. > > > > Section 1 > > > > > >A corollary to ignoring unknown TLVs is having the validation of PDUs > > >be independent from the validation of the TLVs contained in the PDU. > > > > > > nit: this doesn't exactly seem like a "corollary" specifically, but > > > rather a choice that [ISO10589] made (and which keeps some overall sense > > > of consistency between PDU and TLV handling). > > > > > [Les:] Rejecting a PDU because of some issue with a single TLV would mean > that the full set of updates contained in that LSP would not be propagated. > This has a significant impact on the correct operation of the protocol. So I > think this really isn’t an option. I agree that doing anything else would have been a bad idea! I was just suggesting that a different word might be preferred (but am not trying to press the issue). > > > > > > Section 3.1 > > > > > >[ISO10589] defines the behavior required when a PDU is received > > >containing a TLV which is "not recognised". It states (see Sections > > >9.3 - 9.13): > > > > > > This is Sections 9.5 (not 9.3) to 9.13 in the copy I have. > > > > > [Les:] Well spotted. I see you have put your newly acquired copy of ISO > 10589 to good use. Bravo!! Indeed; it was quite helpful to be able to follow along. > > > > Section 3.2 > > > > > >Similarly, the extensions defined by [RFC6233] are not compatible > > >with the behavior
Re: [Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Ben - Thanx for your review. Responses inline. > -Original Message- > From: Benjamin Kaduk via Datatracker > Sent: Monday, July 13, 2020 2:11 PM > To: The IESG > Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; > lsr@ietf.org; > Christian Hopps ; aretana.i...@gmail.com; > cho...@chopps.org > Subject: Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with > COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lsr-isis-invalid-tlv-02: Yes > > 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > -- > COMMENT: > -- > > The shepherd writeup is a bit unclear as to why Proposed Standard is the > right document status (vs., e.g., Informational). I guess it's desired > to have the Updates: relationship to the indicated documents, which > essentially forces it to be standards-track. On the other hand, perhaps > the sense that ignoring a TLV that is specifically disallowed (as > opposed to "merely" unrecognized) is itself a newly specified > requirement, in which case the status as Proposed Standard makes sense > for that reason. It might be worth a little more clarity on which (if > either) of these scenarios are intended. > [Les:] What prompted the writing of this document was a real world interoperability scenario wherein one implementation generated a malformed TLV and a receiving implementation rejected the entire PDU because of it. This resulted in persistent LSPDB inconsistency in the network for a prolonged period with a significant impact on the proper functioning of the network. This failure was considered significant enough that Standards Track seemed appropriate. As the document developed, the authors were encouraged to address some other issues, one of which was clarifying disallowed TLV handling as well. I can understand why Informational track may seem appropriate to you. In early discussions with Alvaro I had suggested that there was no need to write the document - that existing specifications were sufficiently clear. But the fact that - despite existing standards - such an interoperability issue did occur was compelling. The WG also embraced this as useful. > Section 1 > >A corollary to ignoring unknown TLVs is having the validation of PDUs >be independent from the validation of the TLVs contained in the PDU. > > nit: this doesn't exactly seem like a "corollary" specifically, but > rather a choice that [ISO10589] made (and which keeps some overall sense > of consistency between PDU and TLV handling). > [Les:] Rejecting a PDU because of some issue with a single TLV would mean that the full set of updates contained in that LSP would not be propagated. This has a significant impact on the correct operation of the protocol. So I think this really isn’t an option. > Section 3.1 > >[ISO10589] defines the behavior required when a PDU is received >containing a TLV which is "not recognised". It states (see Sections >9.3 - 9.13): > > This is Sections 9.5 (not 9.3) to 9.13 in the copy I have. > [Les:] Well spotted. I see you have put your newly acquired copy of ISO 10589 to good use. Bravo!! > Section 3.2 > >Similarly, the extensions defined by [RFC6233] are not compatible >with the behavior defined in [RFC5304], therefore can only be safely >enabled when all nodes support the extensions. > > nit: I'd argue that technically the extensions are *defined* by 6232, even > though 6233 is what makes their nature (as "allowed in purge") easily > discoverable. > [Les:] Fair enough. I will change this to RFC6232 - which is one of documents updated by this draft. >It is RECOMMENDED that implementations provide controls for the >enablement of behaviors that are not backward compatible. > > We also specifically want the ability to generate but not > process/require at least some of them, right? Is that worth calling out > in addition to just "controls for the enablement"? [Les:] This sentence is serving as a guideline for new behaviors that have backwards compatibility issues. New information which could be safely sent in the presence of legacy routers does not fall into this category. > > Section 3.3 > >a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the >following sentence: > > "As with TLVs,
Re: [Lsr] Secdir last call review of draft-ietf-lsr-isis-invalid-tlv-02
Leif - Thanx for your review. Les > -Original Message- > From: Leif Johansson via Datatracker > Sent: Monday, July 13, 2020 1:55 PM > To: sec...@ietf.org > Cc: last-c...@ietf.org; lsr@ietf.org; > draft-ietf-lsr-isis-invalid-tlv@ietf.org > Subject: Secdir last call review of draft-ietf-lsr-isis-invalid-tlv-02 > > Reviewer: Leif Johansson > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The subject matter is outside my area of expertise but addressing the > obvious attack vector related to authenticated purge messages seems > like a good catch. > > The document is well written and clearly describes what registries > and documents are updated. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Benjamin Kaduk's Yes on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-lsr-isis-invalid-tlv-02: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ -- COMMENT: -- The shepherd writeup is a bit unclear as to why Proposed Standard is the right document status (vs., e.g., Informational). I guess it's desired to have the Updates: relationship to the indicated documents, which essentially forces it to be standards-track. On the other hand, perhaps the sense that ignoring a TLV that is specifically disallowed (as opposed to "merely" unrecognized) is itself a newly specified requirement, in which case the status as Proposed Standard makes sense for that reason. It might be worth a little more clarity on which (if either) of these scenarios are intended. Section 1 A corollary to ignoring unknown TLVs is having the validation of PDUs be independent from the validation of the TLVs contained in the PDU. nit: this doesn't exactly seem like a "corollary" specifically, but rather a choice that [ISO10589] made (and which keeps some overall sense of consistency between PDU and TLV handling). Section 3.1 [ISO10589] defines the behavior required when a PDU is received containing a TLV which is "not recognised". It states (see Sections 9.3 - 9.13): This is Sections 9.5 (not 9.3) to 9.13 in the copy I have. Section 3.2 Similarly, the extensions defined by [RFC6233] are not compatible with the behavior defined in [RFC5304], therefore can only be safely enabled when all nodes support the extensions. nit: I'd argue that technically the extensions are *defined* by 6232, even though 6233 is what makes their nature (as "allowed in purge") easily discoverable. It is RECOMMENDED that implementations provide controls for the enablement of behaviors that are not backward compatible. We also specifically want the ability to generate but not process/require at least some of them, right? Is that worth calling out in addition to just "controls for the enablement"? Section 3.3 a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the following sentence: "As with TLVs, it is required that sub-TLVs which are disallowed MUST be ignored on receipt.". Do we want to say where this logical insertion occurs? Section 3.4 The correct setting for "LSP" is "n". This document updates [RFC6232] by correcting that error. It's slightly interesting that there doesn't seem to be a corresponding Errata Report (but may not be worth doing anything about given that this update is about to be approved). Section 8.1 It's not entirely clear that RFC 7356 is referenced in a normative manner. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Secdir last call review of draft-ietf-lsr-isis-invalid-tlv-02
Reviewer: Leif Johansson Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The subject matter is outside my area of expertise but addressing the obvious attack vector related to authenticated purge messages seems like a good catch. The document is well written and clearly describes what registries and documents are updated. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-02.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 : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-02.txt Pages : 30 Date: 2020-07-13 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisment (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-02 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request WG adoption of TTZ
I support IS-IS TTZ adoption for its value in reducing LSDB through abstraction. -Kiran -Original Message- From: Lsr On Behalf Of Yanhe Fan Sent: Sunday, July 12, 2020 7:33 AM To: Donald Eastlake ; Huaimo Chen Cc: lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ I support adaption of this IS-IS TTZ draft. It is a useful work to address network scalability. Thanks, Yanhe -Original Message- From: Lsr On Behalf Of Donald Eastlake Sent: Friday, July 10, 2020 1:08 PM To: Huaimo Chen Cc: lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ I support adoption of the IS-IS TTZ draft. It seems more flexible and capable although some editorial/nomenclature improvements in the draft would be good. I will send some more detailed suggestions to the authors. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen wrote: > > Hi Chris and Acee, and everyone, > > > > I would like to request working group adoption of "Topology-Transparent > Zone" > > (TTZ for short) > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdata=yxhI0GPxnBm5t0hosQNld4qq7O4bu3V2p4RExVjMcqE%3Dreserved=0 > . > > > This draft comprises the following solutions for helping to improve > scalability: > > 1) abstracting a zone to a single pseudo node in IS-IS, > > 2) abstracting a zone to a single pseudo node in OSPF, > > 3) abstracting a zone to zone edges' full mess in IS-IS, and > > 4) transferring smoothly between a zone and a single pseudo node. > > A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone > or > > non-backbone area). > > > > When a network area becomes (too) big, we can reduce its size in > the sense > > of its LSDB size through abstracting a zone to a single pseudo node or > > abstracting a few zones to a few pseudo nodes. > > > > While a zone is being abstracted (or transferred) to a single > pseudo node, > > the network is stable. There is no or minimum service interruption. > > > > After abstracting a few zones to a few pseudo nodes, if we want to > reconstruct > > them, we can transfer (or roll) any of the pseudo nodes back to its > zone smoothly > > with no or minimum service interruption. > > > > We had a prototype implementation of abstracting a zone to zone > edges' full > > mess in OSPF. The procedures and related protocol extensions for > transferring > > smoothly from a zone to zone edges' full mess are implemented and tested. > > A zone (block of an OSPF area) is smoothly transferred to its edges’ > full mess > > without any routing disruptions. The routes on every router are stable > while > > the zone is being transferred to its edges' mess. It is very easy to > operate > > the transferring. > > > > There are two other drafts for improving scalability: "Area Proxy for > IS-IS" > > (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for > short). > > > > "Area Proxy" > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool > s.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03data=02%7C01%7 > Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a > 3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdata=E95AXx% > 2Bq4Xul3auIUt%2FUI203nvzgDODJDOs8l1Dlk9o%3Dreserved=0 > > abstracts an existing IS-IS L1 area to a single pseudo node. > > > > "Flood Reflection" > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool > s.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01data= > 02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C > 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdat > a=iNunk3YCV%2FiXEEYNYxozwgRlavMPB%2B%2FF1k6K6CCcWkA%3Dreserved=0 > > abstracts an existing IS-IS L1 area to its edges' connections via one > or more > > flood reflectors. > > > > We believe that TTZ has some special advantages even though > > Area Proxy and Flood Reflection are very worthy. We would like > > to ask for working group adoption of TTZ. > > > > Best Regards, > > Huaimo > > ___ > Lsr mailing list > Lsr@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Ckiranm%40future > wei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5 > 591fedc%7C1%7C0%7C637301612416445576sdata=P9I3KSsJb84wDSs6kaVrI%2 > B5bfPRF2MNt1JyTvJea6wc%3Dreserved=0 ___ Lsr mailing list Lsr@ietf.org
Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" wrote: Acee - Inline. > -Original Message- > From: Acee Lindem (acee) > Sent: Monday, July 13, 2020 9:04 AM > To: Les Ginsberg (ginsberg) ; Roman Danyliw > ; The IESG > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft- > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid- > tlv-02: (with COMMENT) > > Hi Les, > > On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" > wrote: > > Roman - > > Thanx for the review. > Inline. > > > -Original Message- > > From: Lsr On Behalf Of Roman Danyliw via > > Datatracker > > Sent: Monday, July 13, 2020 7:40 AM > > To: The IESG > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; > draft- > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > > Subject: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid- > tlv- > > 02: (with COMMENT) > > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss- > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > > > > > -- > > COMMENT: > > -- > > > > I'm glad to see language clarifying error handling. Thanks for the work on > it. > > > > Section 3.2. Per “It is RECOMMENDED that implementations provide > controls > > for > > the enablement of behaviors that are not backward compatible”, I want > to > > double > > check that I’m understanding this sentence correctly. RFC5304 provides > > normative guidance that isn’t backward compatible with ISO10589. > RFC6233 > > provide guidance that isn’t backward compatible with either RFC5304 or > > ISO10589. Is the initial sentence effectively saying that implementations > > should support deployments in configurations that are not backward > > compatible > > (i.e., those using the newer TLVs)? As these changes are covering > security > > matters, I read “controls” in the cyber mitigation sense -- they prevent an > > action, not enable one. > > [Les:] The recommendation is for implementations to provide control as to > when the new (non-backwards compatible) behavior is used. > Without that, an implementation which adds support for (to use one > example) sending the Purge Originator TLV in the presence of MD5 > authentication would simply start sending it and risk the PDU not being > accepted by implementations which had not yet added the support. > > One way of reading this is that "including the POI TLV in purges w MD5 > authentication" is "enablement" of a new feature. Another way of reading it > might be "disablement" of the use of a new feature. > This seems to me to be a semantical distinction. > > The recommendation to use "controls" also does not specify what the > default behavior should be - that is up to the implementation. > > Since there was some confusion, maybe "configurable specification" would > be clearer than "controls". > [Les:] I will certainly wait for Roman's input, but to me the term "controls" means there is a way to control whether a particular behavior is used/not used. (An "on/off" switch comes to mind.) Frankly, I don’t know what the term "configuration specification" means. Maybe if I worked with YANG more I would know. But I suggested "configurable specification"... I think this is clear and more formal than "configuration knob". Thanks, Acee I am open to an alternate term if there really is confusion - but for me you haven't added clarity with your suggestion. Les > Thanks, > Acee > >Les > > > > > > > > > ___ > > Lsr mailing list > > Lsr@ietf.org > >
Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Acee - Inline. > -Original Message- > From: Acee Lindem (acee) > Sent: Monday, July 13, 2020 9:04 AM > To: Les Ginsberg (ginsberg) ; Roman Danyliw > ; The IESG > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft- > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > Subject: Re: [Lsr] Roman Danyliw's No Objection on > draft-ietf-lsr-isis-invalid- > tlv-02: (with COMMENT) > > Hi Les, > > On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" > wrote: > > Roman - > > Thanx for the review. > Inline. > > > -Original Message- > > From: Lsr On Behalf Of Roman Danyliw via > > Datatracker > > Sent: Monday, July 13, 2020 7:40 AM > > To: The IESG > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; > draft- > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > > Subject: [Lsr] Roman Danyliw's No Objection on > draft-ietf-lsr-isis-invalid- > tlv- > > 02: (with COMMENT) > > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss- > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > > > > > -- > > COMMENT: > > -- > > > > I'm glad to see language clarifying error handling. Thanks for the > work on > it. > > > > Section 3.2. Per “It is RECOMMENDED that implementations provide > controls > > for > > the enablement of behaviors that are not backward compatible”, I want > to > > double > > check that I’m understanding this sentence correctly. RFC5304 provides > > normative guidance that isn’t backward compatible with ISO10589. > RFC6233 > > provide guidance that isn’t backward compatible with either RFC5304 or > > ISO10589. Is the initial sentence effectively saying that > implementations > > should support deployments in configurations that are not backward > > compatible > > (i.e., those using the newer TLVs)? As these changes are covering > security > > matters, I read “controls” in the cyber mitigation sense -- they > prevent an > > action, not enable one. > > [Les:] The recommendation is for implementations to provide control as to > when the new (non-backwards compatible) behavior is used. > Without that, an implementation which adds support for (to use one > example) sending the Purge Originator TLV in the presence of MD5 > authentication would simply start sending it and risk the PDU not being > accepted by implementations which had not yet added the support. > > One way of reading this is that "including the POI TLV in purges w MD5 > authentication" is "enablement" of a new feature. Another way of reading it > might be "disablement" of the use of a new feature. > This seems to me to be a semantical distinction. > > The recommendation to use "controls" also does not specify what the > default behavior should be - that is up to the implementation. > > Since there was some confusion, maybe "configurable specification" would > be clearer than "controls". > [Les:] I will certainly wait for Roman's input, but to me the term "controls" means there is a way to control whether a particular behavior is used/not used. (An "on/off" switch comes to mind.) Frankly, I don’t know what the term "configuration specification" means. Maybe if I worked with YANG more I would know. I am open to an alternate term if there really is confusion - but for me you haven't added clarity with your suggestion. Les > Thanks, > Acee > >Les > > > > > > > > > ___ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Hi Les, On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" wrote: Roman - Thanx for the review. Inline. > -Original Message- > From: Lsr On Behalf Of Roman Danyliw via > Datatracker > Sent: Monday, July 13, 2020 7:40 AM > To: The IESG > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft- > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > Subject: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv- > 02: (with COMMENT) > > Roman Danyliw has entered the following ballot position for > draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > -- > COMMENT: > -- > > I'm glad to see language clarifying error handling. Thanks for the work on it. > > Section 3.2. Per “It is RECOMMENDED that implementations provide controls > for > the enablement of behaviors that are not backward compatible”, I want to > double > check that I’m understanding this sentence correctly. RFC5304 provides > normative guidance that isn’t backward compatible with ISO10589. RFC6233 > provide guidance that isn’t backward compatible with either RFC5304 or > ISO10589. Is the initial sentence effectively saying that implementations > should support deployments in configurations that are not backward > compatible > (i.e., those using the newer TLVs)? As these changes are covering security > matters, I read “controls” in the cyber mitigation sense -- they prevent an > action, not enable one. [Les:] The recommendation is for implementations to provide control as to when the new (non-backwards compatible) behavior is used. Without that, an implementation which adds support for (to use one example) sending the Purge Originator TLV in the presence of MD5 authentication would simply start sending it and risk the PDU not being accepted by implementations which had not yet added the support. One way of reading this is that "including the POI TLV in purges w MD5 authentication" is "enablement" of a new feature. Another way of reading it might be "disablement" of the use of a new feature. This seems to me to be a semantical distinction. The recommendation to use "controls" also does not specify what the default behavior should be - that is up to the implementation. Since there was some confusion, maybe "configurable specification" would be clearer than "controls". Thanks, Acee Les > > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Roman - Thanx for the review. Inline. > -Original Message- > From: Lsr On Behalf Of Roman Danyliw via > Datatracker > Sent: Monday, July 13, 2020 7:40 AM > To: The IESG > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft- > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org > Subject: [Lsr] Roman Danyliw's No Objection on > draft-ietf-lsr-isis-invalid-tlv- > 02: (with COMMENT) > > Roman Danyliw has entered the following ballot position for > draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > -- > COMMENT: > -- > > I'm glad to see language clarifying error handling. Thanks for the work on > it. > > Section 3.2. Per “It is RECOMMENDED that implementations provide controls > for > the enablement of behaviors that are not backward compatible”, I want to > double > check that I’m understanding this sentence correctly. RFC5304 provides > normative guidance that isn’t backward compatible with ISO10589. RFC6233 > provide guidance that isn’t backward compatible with either RFC5304 or > ISO10589. Is the initial sentence effectively saying that implementations > should support deployments in configurations that are not backward > compatible > (i.e., those using the newer TLVs)? As these changes are covering security > matters, I read “controls” in the cyber mitigation sense -- they prevent an > action, not enable one. [Les:] The recommendation is for implementations to provide control as to when the new (non-backwards compatible) behavior is used. Without that, an implementation which adds support for (to use one example) sending the Purge Originator TLV in the presence of MD5 authentication would simply start sending it and risk the PDU not being accepted by implementations which had not yet added the support. One way of reading this is that "including the POI TLV in purges w MD5 authentication" is "enablement" of a new feature. Another way of reading it might be "disablement" of the use of a new feature. This seems to me to be a semantical distinction. The recommendation to use "controls" also does not specify what the default behavior should be - that is up to the implementation. Les > > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Murray - Thanx for your review - and for catching the editorial issue. We will address that in the next revision. Les > -Original Message- > From: Murray Kucherawy via Datatracker > Sent: Monday, July 13, 2020 12:21 AM > To: The IESG > Cc: draft-ietf-lsr-isis-invalid-...@ietf.org; lsr-cha...@ietf.org; > lsr@ietf.org; > Christian Hopps ; aretana.i...@gmail.com > Subject: Murray Kucherawy's No Objection on > draft-ietf-lsr-isis-invalid-tlv-02: > (with COMMENT) > > Murray Kucherawy has entered the following ballot position for > draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > > > -- > COMMENT: > -- > > In the Abstract: > > * "... in order to insure that interoperability is maximized." -- That > should be > "ensure". > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ -- COMMENT: -- I'm glad to see language clarifying error handling. Thanks for the work on it. Section 3.2. Per “It is RECOMMENDED that implementations provide controls for the enablement of behaviors that are not backward compatible”, I want to double check that I’m understanding this sentence correctly. RFC5304 provides normative guidance that isn’t backward compatible with ISO10589. RFC6233 provide guidance that isn’t backward compatible with either RFC5304 or ISO10589. Is the initial sentence effectively saying that implementations should support deployments in configurations that are not backward compatible (i.e., those using the newer TLVs)? As these changes are covering security matters, I read “controls” in the cyber mitigation sense -- they prevent an action, not enable one. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request WG adoption of TTZ
I strongly support the adoption of the IS-IS TTZ draft. For the large scale network, if we just run the IS-IS in a large area, the LSDB will be very large. In addition, the convergence time will last for a long time. But TTZ is a good way to reduce the network size and the number of the Link state can be reduced largely. BR, Rouxin From: Lsr on behalf of reta Yang Sent: Monday, July 13, 2020 8:20 PM To: lsr@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ I support adoption of the IS-IS TTZ draft. It is very useful for the large network with abstracting a zone to a single virtual node. The size of the LSDB can be reduced dramatically. best, Reta From: Lsr on behalf of Toy, Mehmet Sent: Monday, July 13, 2020 8:06 AM To: lsr@ietf.org Cc: lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ I support adoption of the IS-IS TTZ draft. Mehmet ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request WG adoption of TTZ
I support adoption of the IS-IS TTZ draft. It is very useful for the large network with abstracting a zone to a single virtual node. The size of the LSDB can be reduced dramatically. best, Reta From: Lsr on behalf of Toy, Mehmet Sent: Monday, July 13, 2020 8:06 AM To: lsr@ietf.org Cc: lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ I support adoption of the IS-IS TTZ draft. Mehmet ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ -- COMMENT: -- In the Abstract: * "... in order to insure that interoperability is maximized." -- That should be "ensure". ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
