Re: [Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

Acee/Chris/ADs,
The wide use of IS-IS in different parts of the network/architectures requires a different approach to scale these implementations outside of breaking them into multiple domains/areas, which has its own set of challenges.

Work in this area is important to solve these challenges and I’d like to see the WG progress in this effort without implying any preference to the drafts mentioned below

Thanks,
Luay

From: Luay Jalil <luayjalil.ietf@gmail.com>
Date: Wednesday, January 29, 2020 at 5:40 PM
To: Luay <luay.jalil@one.verizon.com>
Subject: [E] Fwd: Lsr Digest, Vol 24, Issue 48

On Jan 27, 2020, at 2:00 PM, lsr-request@ietf.org<mailto:lsr-request@ietf.org> wrote:

Send Lsr mailing list submissions to
 lsr@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=e7XzcNmqH2gFocEN94vBw8WkH_Bv_55vXDp_LPy8YVg&e=>
or, via email, send a message with subject or body 'help' to
 lsr-request@ietf.org

You can reach the person managing the list at
 lsr-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Lsr digest..."

Today's Topics:

   1. IS-IS Requirements for Area Abstraction (Corrected Alias for
      ADs) (Acee Lindem (acee))
   2. Re: IS-IS Requirements for Area Abstraction (Corrected Alias
      for ADs) (Alvaro Retana)
From:

"Acee Lindem (acee)"

To:

"lsr@ietf.org"

Cc:

"rtg-ads@ietf.org"

Sent:

Mon Jan 27 11:17:49 CST 2020

Subject:

[Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

Speaking as WG Co-chair:

At IETF 107, we had a protracted discussion of several drafts having  goal of reducing the amount of link-state information that must be flooded into the level-2 area. We have two drafts that do this essentially via abstraction of the level-1 areas. These are:

https://www.ietf.org/id/draft-li-lsr-isis-area-proxy-01.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dli-2Dlsr-2Disis-2Darea-2Dproxy-2D01.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=m1VZtHwoBnVM6NLTkyyJ0OlR9Y_wfJV5Zytor2-5v3w&e=>
https://www.ietf.org/id/draft-chen-isis-ttz-07.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dchen-2Disis-2Dttz-2D07.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=NmfKylryP8aeh12mFSgzJk8sBgAd0qZhIBNOgrV5vGA&e=>

There are various reasons why these drafts can’t consolidated involving both IPR and government restrictions. Refer to https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_106_materials_minutes-2D106-2Dlsr-2D00&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=zqKKw4v2gm2mx1LZo4WWmSF06YB14M9PChnOYzpB5Gk&e=> for the complete discussion.

We have another draft that also reduces the amount of link-state information each IS-IS router must maintain but using IS-IS reflectors. This is slightly different but also avoids leaking all the level-1 area link-state to the level-2 area.

https://www.ietf.org/id/draft-przygienda-lsr-flood-reflection-01.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dprzygienda-2Dlsr-2Dflood-2Dreflection-2D01.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=h-CP1Os5HiQ4PfwiVXf5kEKNktTL4T-0mojVVCBKFi8&e=>

Given the amount of overlap and the conflicts amongst these drafts, the chairs/Ads are now asking whether there is a really a strong requirement to advance one or more of these documents. Especially given that we are already moving forward with both IS-IS/OSPF flooding reductions and the Hierarchal IS-IS work. Additionally,  we anticipate we’ll reach an impasse in consolidating these drafts. We’d really like to hear from the operators that would deploy these mechanisms.

Thanks,
Acee and Chris

From:

Alvaro Retana

To:

"lsr@ietf.org"

Cc:

"rtg-ads@ietf.org" , "Acee Lindem (acee)"

Sent:

Mon Jan 27 13:40:24 CST 2020

Subject:

Re: [Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

FYI…

Because I am one of the co-authors of draft-chen-isis-ttz, I am recusing myself from this discussion.  Martin will be the responsible AD for it, should one be needed.

Alvaro.

On January 27, 2020 at 1:27:13 PM, Acee Lindem (acee) (acee@cisco.com<mailto:acee@cisco.com>) wrote:
Speaking as WG Co-chair:

At IETF 107, we had a protracted discussion of several drafts having  goal of reducing the amount of link-state information that must be flooded into the level-2 area. We have two drafts that do this essentially via abstraction of the level-1 areas. These are:

https://www.ietf.org/id/draft-li-lsr-isis-area-proxy-01.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dli-2Dlsr-2Disis-2Darea-2Dproxy-2D01.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=m1VZtHwoBnVM6NLTkyyJ0OlR9Y_wfJV5Zytor2-5v3w&e=>
https://www.ietf.org/id/draft-chen-isis-ttz-07.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dchen-2Disis-2Dttz-2D07.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=NmfKylryP8aeh12mFSgzJk8sBgAd0qZhIBNOgrV5vGA&e=>

There are various reasons why these drafts can’t consolidated involving both IPR and government restrictions. Refer to https://datatracker.ietf.org/meeting/106/materials/minutes-106-lsr-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_106_materials_minutes-2D106-2Dlsr-2D00&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=zqKKw4v2gm2mx1LZo4WWmSF06YB14M9PChnOYzpB5Gk&e=> for the complete discussion.

We have another draft that also reduces the amount of link-state information each IS-IS router must maintain but using IS-IS reflectors. This is slightly different but also avoids leaking all the level-1 area link-state to the level-2 area.

https://www.ietf.org/id/draft-przygienda-lsr-flood-reflection-01.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dprzygienda-2Dlsr-2Dflood-2Dreflection-2D01.txt&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=h-CP1Os5HiQ4PfwiVXf5kEKNktTL4T-0mojVVCBKFi8&e=>

Given the amount of overlap and the conflicts amongst these drafts, the chairs/Ads are now asking whether there is a really a strong requirement to advance one or more of these documents. Especially given that we are already moving forward with both IS-IS/OSPF flooding reductions and the Hierarchal IS-IS work. Additionally,  we anticipate we’ll reach an impasse in consolidating these drafts. We’d really like to hear from the operators that would deploy these mechanisms.

Thanks,
Acee and Chris

________________________________

Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=z1foUEk3_xpkIgCZi8-X74yChqaWmksE-MWtr1XMDVU&s=e7XzcNmqH2gFocEN94vBw8WkH_Bv_55vXDp_LPy8YVg&e=>