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

Alia Atlas <akatlas@gmail.com> Mon, 05 February 2018 18:02 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300CE12D862; Mon, 5 Feb 2018 10:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7fnpnUE1Sla; Mon, 5 Feb 2018 10:02:18 -0800 (PST)
Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B817127369; Mon, 5 Feb 2018 10:02:18 -0800 (PST)
Received: by mail-ot0-x236.google.com with SMTP id s4so3521636oth.7; Mon, 05 Feb 2018 10:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mkQfi4DVPLSgcCnGMPiP1rvRbEm1aMwW0hsx1JP6dfg=; b=vFu9mkvr4JIxQj4rnfEeSDCBpqlxGKk5My1N2fPEqA04Toykumly7xDhKBGu2m61sj KqYMn89jn5dH1ihnF9mP3R/NQi0+eQWK7E5kiKfNYrVFYTvNmxMy2OM2QiDgps1PMqhP J/l0AZaowbndIH02YUI+CznFq1rrlekKVv3gIrw6V9SVnsdxZDiXqNLzerEoDj3m35Mg AaxgK8b8ipGpsz7BtDhYWnj/umhZtZfXyJXTfkmGRd2f3POg4I8AlruefUMnNNDPNDXz lCrQTTUZUzA1OKvmglXh1+o+9VdHYCEU4tvvlz7nlVS+u/sxm6vwDUQ45GPP2WBxp3Vl PAuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mkQfi4DVPLSgcCnGMPiP1rvRbEm1aMwW0hsx1JP6dfg=; b=JeE0QPwFNaLd9FtOsoXy38x8W629QakTJmwL723grmsaQRGDwNXHVKYE4voCR39M/i 9SdMJZwXQvOPh8SbYaHYMyi8qxvvtIvQz5LJUQlv998RJ4FWVuOLG881dpoAL/lT8/Oe Xx1Wfzzc8DVqG7qQriyrjOw75nH0q35PbbINNuiny3baIQCKUt6iqAFz5k8X6ks7yYbF Nw1G6eW4ZQpq28indMgMjIKNVS6HRO+oGQ44JVa7O1UyLe9gTLrG6SYzxdRJquiEit1D 8xbqNaaA8GwHbnC25xxSMbnYpc5U01cNJMnZsaxATlTskmCxb12LJFbhibZrusnuTZlU 2ckA==
X-Gm-Message-State: AKwxytd0FJszrEPIr3SOopnet75O8P2j19QTTuBm/rQPieM9O8daRBcV IWihT3wMXxfGmnEjGOHR8Kev/cBMI4ipjHI00+yQBqwi
X-Google-Smtp-Source: AH8x225UXlDXUbMmpaiBFh27UlwXYeRRyTGh+bcqs8t3IKzzLb5FGFz4hzYjxZUV8CVIB+lcUD+Ri4/CTCqyrN7sgWc=
X-Received: by 10.157.12.168 with SMTP id b37mr17310749otb.6.1517853736988; Mon, 05 Feb 2018 10:02:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.40.246 with HTTP; Mon, 5 Feb 2018 10:02:16 -0800 (PST)
In-Reply-To: <CAG4d1rd4Az1KzExrQ2vttJDQ4HBLMEzm3x88=iZAx47+xneESA@mail.gmail.com>
References: <CAG4d1rfR5Y85T_wNSVXB0WL4C8THyAkgevr6DyH1xcO=R+sOVQ@mail.gmail.com> <B38DA8C7-CA03-42F1-BF2C-5E9EF6A39790@nokia.com> <CAG4d1rd4Az1KzExrQ2vttJDQ4HBLMEzm3x88=iZAx47+xneESA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Mon, 5 Feb 2018 13:02:16 -0500
Message-ID: <CAG4d1rcEGMbCH+MSyd_fMFx79tTd4g7oswTktVm5KA4mBZ3Qbw@mail.gmail.com>
To: "isis-wg@ietf.org" <isis-wg@ietf.org>, OSPF List <ospf@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140af66d07b0805647adc8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/3k98Er9FZFLLnZRZeZIzNOl8hwI>
Subject: Re: [Isis-wg] Link-State Routing WG charter
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2018 18:02:21 -0000

To finish this up, I also got a better wording suggestion from Hannes for
the data-center support.
The charter is on the IESG telechat this Thurs for internal review.  There
will still be a couple weeks
for the external review before it is finally approved.

Please take a look at https://datatracker.ietf.org/doc/charter-ietf-lsr/
(charter-ietf-lsr-00-06) for the
current proposed charter text.  That is also copied below:

==============

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-WG’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. LSR-WG will continue to support Layer 2 routing (for
example TRILL work) as needed.

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.

In addition to ongoing maintenance, the following topics are expected to be
among the work-items at the time of chartering.

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) Improving the transport/io/flooding behavior of the protocols to better
support
   dense meshed network topologies, such as are commonly used in data
centers.

The Link-State Routing (LSR) Working Group will coordinate with other
working
groups, such as RTGWG, SPRING, MPLS, TEAS, PCE, V6OPS, and 6MAN, to
understand
the need for extensions and to confirm that the planned work meets the needs
and is compatible with IS-IS and/or OSPF from functional, architectural and
performance point of views.  LSR-WG will coordinate with CCAMP and BIER on
their extensions to the LSR IGPs as applicable to LSR protocol operation and
scale.  LSR-WG should coordinate with other WGs as needed.

=============

Regards,
Alia

On Thu, Jan 25, 2018 at 10:07 PM, Alia Atlas <akatlas@gmail.com> wrote:

> Andrew,
>
>
> I like that improvement.
>
> Thanks,
> Alia
>
> On Thu, Jan 25, 2018 at 9:06 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
> andrew.dolganow@nokia.com> wrote:
>
>> One comment – I would add a bit of text at the end of the below-quoted
>> sentence to ensure that “extensions planned to meet the needs” do not
>> create stability/performance problems to IGPs. I proposed a text in red for
>> that:
>>
>>
>>
>> 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 and is compatible with both IS-IS and OSPF from
>> functional, architectural and performance point of views
>>
>>
>>
>> Andrew
>>
>>
>>
>> *From: *Isis-wg <isis-wg-bounces@ietf.org> on behalf of Alia Atlas <
>> akatlas@gmail.com>
>> *Date: *Thursday, January 25, 2018 at 1:19 AM
>> *To: *"isis-wg@ietf.org" <isis-wg@ietf.org>rg>, OSPF List <ospf@ietf.org>
>> *Subject: *[Isis-wg] Link-State Routing WG charter
>>
>>
>>
>> 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.
>>
>>
>>
>> https://datatracker.ietf.org/doc/charter-ietf-lsr/
>>
>>
>>
>> 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.
>>
>>
>>
>> Regards,
>>
>> Alia
>>
>
>