Re: [Isis-wg] Link-State Routing WG charter

"Acee Lindem (acee)" <> Wed, 24 January 2018 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A310127419; Wed, 24 Jan 2018 09:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7EZwP8GWg6Sn; Wed, 24 Jan 2018 09:54:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E0971273E2; Wed, 24 Jan 2018 09:54:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=24904; q=dns/txt; s=iport; t=1516816457; x=1518026057; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qNucIrR9FqY+HZHfTxGLB0xwXlMqqodysIDHwbGE8IQ=; b=JORD20wShherSJgtnCJpYU2Vm3fOyqEkowG0LCRuX6+WqHFfEJHSLpaY 2NKZQX/9mCArADeQe7gbckKNZCBKuHVx2zZ4mGU99DaXW9iG0ooF3E51P gB4MbZahRA2wY0uUMV5OQfv1w1l1fijp0xlyK/1xHXPzT8zaEUbulO1mV 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.46,408,1511827200"; d="scan'208,217";a="345470576"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 17:54:15 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w0OHsFBO022307 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jan 2018 17:54:15 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 24 Jan 2018 12:54:14 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 24 Jan 2018 12:54:14 -0500
From: "Acee Lindem (acee)" <>
To: Alia Atlas <>, Stewart Bryant <>
CC: OSPF List <>, "" <>
Thread-Topic: [Isis-wg] Link-State Routing WG charter
Thread-Index: AQHTlTd2tON3zkKDhEOulGsQDsiun6ODm+WAgAAC4gD//697AA==
Date: Wed, 24 Jan 2018 17:54:14 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5418BD5D9E5E49F1A44CFC60C3EDF391ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] Link-State Routing WG charter
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jan 2018 17:54:20 -0000

How about:

LSR will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as
applicable to LSV protocol operation and scale.


From: Isis-wg <> on behalf of Alia Atlas <>
Date: Wednesday, January 24, 2018 at 12:42 PM
To: Stewart Bryant <>
Cc: OSPF WG List <>rg>, "" <>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Stewart,

Thanks for the quick feedback.  Feel free to provide suggestions for text changes if you have them.
You've certainly written enough charters :-)


On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant <<>> wrote:

I think that this merger is long overdue, and hopefully it will help new features to be written in an aligned way.

I think the remit to perform general maintenance should slightly clarified since the way the charter is written they look like they are at a lower priority than the enumerated list.

I would have thought that "LSR can coordinate with CCAMP and BIER on their extensions " should have been more directive.

- Stewart

On 24/01/2018 17:18, Alia Atlas wrote:
Here is the proposed charter for the LSR working group
that will be created from the SPF and ISIS working groups.

This is scheduled for internal review for the IESG telechat on February 8.

The Link-State Routing (LSR) Working Group is chartered to document current protocol implementation practices and improvements, protocol usage scenarios, maintenance and extensions of link-state routing interior gateway protocols (IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3.  The LSR Working Group is formed by merging the isis and ospf WGs and will take on all their existing adopted work at the time of chartering.

IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and additional RFC standards with extensions to support IP that has been deployed in the Internet for decades.  For the IS-IS protocol, LSR’s work is focused on IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The LSR WG will interact with other standards bodies that have responsible for standardizing IS-IS.

OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949].

The LSR Working Group will generally manage its specific work items by milestones agreed with the responsible Area Director.

The following topics are expected to be an initial focus:

1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA Extendibility.
2) Extensions needed for Segment Routing and associated architectural changes
3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions
4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src-routing]
5) Potentially, extensions to better support specific network topologies such as
ones commonly used in data centers.

The Link-State Routing (LSR) Working Group will coordinate with other working groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to understand the need for extensions and to confirm that the planned work meets the needs.  LSR can coordinate with CCAMP and BIER on their extensions to the LSR IGPs as useful.  LSR may coordinate with other WGs as needed.



Isis-wg mailing list<>