To expand on this a bit, the point of the draft extensions is to add additional levels of hierarchy and use existing mechanisms (leaking, summarization) to have traffic flow up/down the hierarchy. The intent is NOT to bypass the hierarchy.
People can use multiple instances and redistribution to do whatever they may wish. In that context two instances of IS-IS are no different then one instance of two different protocols. But this is decidedly NOT the intent of the draft. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of tony...@tony.li Sent: Friday, August 16, 2019 11:01 AM To: Tony Li <tony...@tony.li> Cc: lsr@ietf.org; Aijun Wang <wangai...@tsinghua.org.cn>; Robert Raszuk <rob...@raszuk.net> Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01 Hi Aijun, Les kindly points out that what I’ve suggested here is completely non-standard and requires multiple IS-IS instances. Tony On Aug 16, 2019, at 9:03 AM, tony...@tony.li<mailto:tony...@tony.li> wrote: Hi Aijun, If, as you stated, we connect R1 and R7 via one link(although we will not do so, if we design the network hierarchically), how you flood the link information hierarchically but let the traffic between the two connected L1 area bypass the L2 area? The link between R1 and R7 needs to belong to either the top area or the bottom area. R1 or R7 needs to participate in two areas and leak routes between the two areas. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
