[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Robert Wilton 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: -- The document is short and easy to read, thanks! However, I was sure whether I should put a DISCUSS on this document for section 3.4. I find that the quoted paragraph from RFC6232 to be badly worded: "The POI TLV SHOULD be found in all purges and MUST NOT be found in LSPs with a non-zero Remaining Lifetime." Taking a strict reading of this, my interpretation is that an implementation is not compliant to RFC 6232 if it happens to receive a POI TLV in an LSP with non-zero remaining lifetime! Further, this text then arguably conflicts with earlier parts of this document regarding how unrecognized or bad TLVs should be handled. Hence, given that RFC6232 is being updated, I would prefer it if this document also updated RFC6232 to clarify the above paragraph to something like: "The POI TLV SHOULD be sent in all purges and MUST NOT be sent in LSPs with a non-zero Remaining Lifetime." One other minor comment: It is RECOMMENDED that implementations provide controls for the enablement of behaviors that are not backward compatible. Is this covered by the existing ISIS YANG model, or included in the latest update to that YANG model? Regards, Rob ___ 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, Roman, On 7/14/20, 7:15 AM, "Roman Danyliw" wrote: Hi Les and Acee! > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Monday, July 13, 2020 11:43 PM > To: Acee Lindem (acee) ; 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) > > 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. I appreciate the quick response. No need to further debate the definition of "controls". The proposal above resolves my concerns. Thank you! This works for me. Thanks, Acee Regards, Roman >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
Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Rob - Thanx for the review. Responses inline. > -Original Message- > From: Robert Wilton via Datatracker > Sent: Tuesday, July 14, 2020 2:25 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; > cho...@chopps.org > Subject: Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: > (with COMMENT) > > Robert Wilton 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: > -- > > The document is short and easy to read, thanks! However, I was sure > whether I > should put a DISCUSS on this document for section 3.4. > > I find that the quoted paragraph from RFC6232 to be badly worded: > > "The POI TLV SHOULD be found in all purges and >MUST NOT be found in LSPs with a non-zero >Remaining Lifetime." > > Taking a strict reading of this, my interpretation is that an implementation > is > not compliant to RFC 6232 if it happens to receive a POI TLV in an LSP with > non-zero remaining lifetime! Further, this text then arguably conflicts with > earlier parts of this document regarding how unrecognized or bad TLVs > should be > handled. > > Hence, given that RFC6232 is being updated, I would prefer it if this > document > also updated RFC6232 to clarify the above paragraph to something like: > > "The POI TLV SHOULD be sent in all purges and >MUST NOT be sent in LSPs with a non-zero >Remaining Lifetime." > [Les:] I have no objection to the wording change. But, I do find your interpretation that "an implementation which receives...is non-compliant" a bit pedantic (no offense intended). Clearly an implementation cannot control what it receives. But I agree your proposed wording change is more "traditional". > One other minor comment: > > It is RECOMMENDED that implementations provide controls for the > enablement > of behaviors that are not backward compatible. > > Is this covered by the existing ISIS YANG model, or included in the latest > update to that YANG model? [Les:] Note that the wording of this has been revised based on recent comments and now speaks to future instances as well as existing ones. But to answer your question, this isn’t just "one thing". For each non-backwards compatible behavior I would expect that an implementation would need to provide a separate control. So coverage in a YANG model is going to be on a feature-by-feature basis. There is no one generic "backwards-compatible-knob" that will suffice. More details I leave to the team that will be working on extensions to the base protocol YANG model. Les > > Regards, > Rob > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Request WG adoption of TTZ
Linda, On 7/14/20, 1:26 PM, "Linda Dunbar" wrote: Acee, We have deployment of using BGP to group a set of SDWAN nodes as one entity and exchange link/paths/ports information among sites/nodes. TTZ could be another option. I don't see how it would work to replace BGP and RR with IS-IS TTZ for SDWAN Fabric setup. However, that is probably a topic that would be better addressed in the RTG WG. Thanks, Acee Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 11:59 AM To: Linda Dunbar ; Christian Hopps Cc: LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ Linda, So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed this? __ Acee On 7/14/20, 12:52 PM, "Linda Dunbar" wrote: Christian, The SDWAN use case is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as one Virtual Node. Linda -Original Message- From: Christian Hopps Sent: Saturday, July 11, 2020 6:42 AM To: Linda Dunbar Cc: Christian Hopps ; LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ > On Jul 10, 2020, at 4:39 PM, Linda Dunbar wrote: > > I also support the adoption of TTZ draft. > > The Virtual Zone concept would be very useful for the Overlay networks. The proposed TTZ can group a set of nodes not geographically together into one virtual area to scale virtual overlay networks with lots of nodes. Those kind overlay networks are getting more momentum in SDWAN and CDN environment. I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of nodes as a single node (or subset of nodes in early work) to reduce the link-state DB size and flooding requirements, AFAICT. Thanks, Chris. [As WG member] > > Linda Dunbar > > From: Lsr On Behalf Of LEI LIU > Sent: Friday, July 10, 2020 12:42 PM > To: Huaimo Chen > Cc: lsr@ietf.org; lsr-cha...@ietf.org > Subject: Re: [Lsr] Request WG adoption of TTZ > > I support the adoption of the TTZ draft. > > The operation on TTZ is simple. Smooth transferring between a zone and a single node will improve customer experience. The work on TTZ should be moved forward. > > Thanks, > Best regards, > > Lei > > On Thu, Jun 18, 2020 at 8: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%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715sdata=%2F4hwW%2FHPgVyrbjmdXOSZCZezIaDj8UbVrlXWDLjrgkU%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
Re: [Lsr] Request WG adoption of TTZ
Acee, Many networks have BGP or/and ISIS. Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS is discussed LSR WG. The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion should be in the LSR Wg, instead of RTGwg (in my opinion). Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But this TTZ zone draft is not about replacing BGP. Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 12:32 PM To: Linda Dunbar ; Christian Hopps Cc: LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ Linda, On 7/14/20, 1:26 PM, "Linda Dunbar" wrote: Acee, We have deployment of using BGP to group a set of SDWAN nodes as one entity and exchange link/paths/ports information among sites/nodes. TTZ could be another option. I don't see how it would work to replace BGP and RR with IS-IS TTZ for SDWAN Fabric setup. However, that is probably a topic that would be better addressed in the RTG WG. Thanks, Acee Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 11:59 AM To: Linda Dunbar ; Christian Hopps Cc: LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ Linda, So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed this? __ Acee On 7/14/20, 12:52 PM, "Linda Dunbar" wrote: Christian, The SDWAN use case is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as one Virtual Node. Linda -Original Message- From: Christian Hopps Sent: Saturday, July 11, 2020 6:42 AM To: Linda Dunbar Cc: Christian Hopps ; LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ > On Jul 10, 2020, at 4:39 PM, Linda Dunbar wrote: > > I also support the adoption of TTZ draft. > > The Virtual Zone concept would be very useful for the Overlay networks. The proposed TTZ can group a set of nodes not geographically together into one virtual area to scale virtual overlay networks with lots of nodes. Those kind overlay networks are getting more momentum in SDWAN and CDN environment. I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of nodes as a single node (or subset of nodes in early work) to reduce the link-state DB size and flooding requirements, AFAICT. Thanks, Chris. [As WG member] > > Linda Dunbar > > From: Lsr On Behalf Of LEI LIU > Sent: Friday, July 10, 2020 12:42 PM > To: Huaimo Chen > Cc: lsr@ietf.org; lsr-cha...@ietf.org > Subject: Re: [Lsr] Request WG adoption of TTZ > > I support the adoption of the TTZ draft. > > The operation on TTZ is simple. Smooth transferring between a zone and a single node will improve customer experience. The work on TTZ should be moved forward. > > Thanks, > Best regards, > > Lei > > On Thu, Jun 18, 2020 at 8: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%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%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
Re: [Lsr] Request WG adoption of TTZ
Linda, So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed this? __ Acee On 7/14/20, 12:52 PM, "Linda Dunbar" wrote: Christian, The SDWAN use case is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as one Virtual Node. Linda -Original Message- From: Christian Hopps Sent: Saturday, July 11, 2020 6:42 AM To: Linda Dunbar Cc: Christian Hopps ; LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ > On Jul 10, 2020, at 4:39 PM, Linda Dunbar wrote: > > I also support the adoption of TTZ draft. > > The Virtual Zone concept would be very useful for the Overlay networks. The proposed TTZ can group a set of nodes not geographically together into one virtual area to scale virtual overlay networks with lots of nodes. Those kind overlay networks are getting more momentum in SDWAN and CDN environment. I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of nodes as a single node (or subset of nodes in early work) to reduce the link-state DB size and flooding requirements, AFAICT. Thanks, Chris. [As WG member] > > Linda Dunbar > > From: Lsr On Behalf Of LEI LIU > Sent: Friday, July 10, 2020 12:42 PM > To: Huaimo Chen > Cc: lsr@ietf.org; lsr-cha...@ietf.org > Subject: Re: [Lsr] Request WG adoption of TTZ > > I support the adoption of the TTZ draft. > > The operation on TTZ is simple. Smooth transferring between a zone and a single node will improve customer experience. The work on TTZ should be moved forward. > > Thanks, > Best regards, > > Lei > > On Thu, Jun 18, 2020 at 8: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://datatracker.ietf.org/doc/draft-chen-isis-ttz/ . > > > > 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://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03 > > abstracts an existing IS-IS L1 area to a single pseudo node. > > > > "Flood Reflection" https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 > > 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 >
Re: [Lsr] Request WG adoption of TTZ
Acee, We have deployment of using BGP to group a set of SDWAN nodes as one entity and exchange link/paths/ports information among sites/nodes. TTZ could be another option. Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 11:59 AM To: Linda Dunbar ; Christian Hopps Cc: LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ Linda, So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed this? __ Acee On 7/14/20, 12:52 PM, "Linda Dunbar" wrote: Christian, The SDWAN use case is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as one Virtual Node. Linda -Original Message- From: Christian Hopps Sent: Saturday, July 11, 2020 6:42 AM To: Linda Dunbar Cc: Christian Hopps ; LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ > On Jul 10, 2020, at 4:39 PM, Linda Dunbar wrote: > > I also support the adoption of TTZ draft. > > The Virtual Zone concept would be very useful for the Overlay networks. The proposed TTZ can group a set of nodes not geographically together into one virtual area to scale virtual overlay networks with lots of nodes. Those kind overlay networks are getting more momentum in SDWAN and CDN environment. I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of nodes as a single node (or subset of nodes in early work) to reduce the link-state DB size and flooding requirements, AFAICT. Thanks, Chris. [As WG member] > > Linda Dunbar > > From: Lsr On Behalf Of LEI LIU > Sent: Friday, July 10, 2020 12:42 PM > To: Huaimo Chen > Cc: lsr@ietf.org; lsr-cha...@ietf.org > Subject: Re: [Lsr] Request WG adoption of TTZ > > I support the adoption of the TTZ draft. > > The operation on TTZ is simple. Smooth transferring between a zone and a single node will improve customer experience. The work on TTZ should be moved forward. > > Thanks, > Best regards, > > Lei > > On Thu, Jun 18, 2020 at 8: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%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715sdata=%2F4hwW%2FHPgVyrbjmdXOSZCZezIaDj8UbVrlXWDLjrgkU%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"
Re: [Lsr] Request WG adoption of TTZ
Christian, The SDWAN use case is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as one Virtual Node. Linda -Original Message- From: Christian Hopps Sent: Saturday, July 11, 2020 6:42 AM To: Linda Dunbar Cc: Christian Hopps ; LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ > On Jul 10, 2020, at 4:39 PM, Linda Dunbar wrote: > > I also support the adoption of TTZ draft. > > The Virtual Zone concept would be very useful for the Overlay networks. The > proposed TTZ can group a set of nodes not geographically together into one > virtual area to scale virtual overlay networks with lots of nodes. Those kind > overlay networks are getting more momentum in SDWAN and CDN environment. I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of nodes as a single node (or subset of nodes in early work) to reduce the link-state DB size and flooding requirements, AFAICT. Thanks, Chris. [As WG member] > > Linda Dunbar > > From: Lsr On Behalf Of LEI LIU > Sent: Friday, July 10, 2020 12:42 PM > To: Huaimo Chen > Cc: lsr@ietf.org; lsr-cha...@ietf.org > Subject: Re: [Lsr] Request WG adoption of TTZ > > I support the adoption of the TTZ draft. > > The operation on TTZ is simple. Smooth transferring between a zone and a > single node will improve customer experience. The work on TTZ should be moved > forward. > > Thanks, > Best regards, > > Lei > > On Thu, Jun 18, 2020 at 8: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://datatracker.ietf.org/doc/draft-chen-isis-ttz/ . > > > > 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://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03 > > abstracts an existing IS-IS L1 area to a single pseudo node. > > > > "Flood Reflection" > https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 > > 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://www.ietf.org/mailman/listinfo/lsr > > > ___ > 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] Request WG adoption of TTZ
Linda, On 7/14/20, 1:57 PM, "Linda Dunbar" wrote: Acee, Many networks have BGP or/and ISIS. Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS is discussed LSR WG. The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion should be in the LSR Wg, instead of RTGwg (in my opinion). Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But this TTZ zone draft is not about replacing BGP. But you just said "TTZ is another option?" And if IS-IS isn't running over the SDWAN overlay, how is IS-IS TTZ even applicable to solving any problem in SDWAN? Thanks, Acee Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 12:32 PM To: Linda Dunbar ; Christian Hopps Cc: LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ Linda, On 7/14/20, 1:26 PM, "Linda Dunbar" wrote: Acee, We have deployment of using BGP to group a set of SDWAN nodes as one entity and exchange link/paths/ports information among sites/nodes. TTZ could be another option. I don't see how it would work to replace BGP and RR with IS-IS TTZ for SDWAN Fabric setup. However, that is probably a topic that would be better addressed in the RTG WG. Thanks, Acee Linda -Original Message- From: Acee Lindem (acee) Sent: Tuesday, July 14, 2020 11:59 AM To: Linda Dunbar ; Christian Hopps Cc: LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ Linda, So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed this? __ Acee On 7/14/20, 12:52 PM, "Linda Dunbar" wrote: Christian, The SDWAN use case is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as one Virtual Node. Linda -Original Message- From: Christian Hopps Sent: Saturday, July 11, 2020 6:42 AM To: Linda Dunbar Cc: Christian Hopps ; LEI LIU ; Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org Subject: Re: [Lsr] Request WG adoption of TTZ > On Jul 10, 2020, at 4:39 PM, Linda Dunbar wrote: > > I also support the adoption of TTZ draft. > > The Virtual Zone concept would be very useful for the Overlay networks. The proposed TTZ can group a set of nodes not geographically together into one virtual area to scale virtual overlay networks with lots of nodes. Those kind overlay networks are getting more momentum in SDWAN and CDN environment. I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of nodes as a single node (or subset of nodes in early work) to reduce the link-state DB size and flooding requirements, AFAICT. Thanks, Chris. [As WG member] > > Linda Dunbar > > From: Lsr On Behalf Of LEI LIU > Sent: Friday, July 10, 2020 12:42 PM > To: Huaimo Chen > Cc: lsr@ietf.org; lsr-cha...@ietf.org > Subject: Re: [Lsr] Request WG adoption of TTZ > > I support the adoption of the TTZ draft. > > The operation on TTZ is simple. Smooth transferring between a zone and a single node will improve customer experience. The work on TTZ should be moved forward. > > Thanks, > Best regards, > > Lei > > On Thu, Jun 18, 2020 at 8: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%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%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.
Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Hi Les and Acee! > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Monday, July 13, 2020 11:43 PM > To: Acee Lindem (acee) ; 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) > > 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. I appreciate the quick response. No need to further debate the definition of "controls". The proposal above resolves my concerns. Thank you! Regards, Roman >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 > >
