Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B167E129469 for ; Thu, 4 May 2017 16:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 pEviDsZ97MI8 for ; Thu, 4 May 2017 16:30:14 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 39C54126D05 for ; Thu, 4 May 2017 16:30:13 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w64so10433072wma.0 for ; Thu, 04 May 2017 16:30:13 -0700 (PDT) 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=AZi2Fok7rnCCs7uAn2zczIEFKdtqR0lixapBUZyU+MI=; b=hoopyK74guJUqpZ9ghW2RueFD+QqYtjH2yi/uq+lByizJfDBaROtH3Rtyeo7CUr7WB 2jua3eN/EdLwyMD9qXyxZhGXdf1aDBJQeno5vqJz4y6za2UVQjht/eEOLtgm9N8cwqlB fyoiv0x4aAU2wIP9qHowu7vtOD4YEBZgpjbn6MilBbuUKg9PCghnArdg0mXSJo37MBBI bHB9w++MtOgmmrn/WlwI+IPd7bU82at7genLUbnrsjX2S8kyo5DxqYGKWBSR3liSI7aY 6B2Sawm/EKv2EjUxwjQrAyQHa4HafPLFnsnR0km0TP4Kwp7wUK+JYpRFCqqdyuCIIKeb mS3w== 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=AZi2Fok7rnCCs7uAn2zczIEFKdtqR0lixapBUZyU+MI=; b=AUyJMQlUfeG5AkpKRaw8paANf2c/iKbGhQSm7pHMVRn+JH6wQb3/o7EOSyEkF//DI6 /6I3ymgzJmHVbfvO8KxE44Ttcx0xSAmPL8AEA1cXK1P1nmaWn1UERFseHxVRzHY82BJU 3LpKAjY3X7op5JYTPEO95oLZi7qIWT2tKh3urk6Fv3f3G8Bkcxt6ifoZlIQvK0PCTQN8 a9hX0/Y4bNZQkSMRpTHkLMUgCsIFvkXM2zK4vY7pK3DQhpfo6OLwKaXHYYMg2yUaaU7W 7QPGV34kRF8icPwJHt7bP7N+wh36G0UIJ34jgsS/EmVy/a41NkdvO/B7ZSMxiuN+n5LH zjvA== X-Gm-Message-State: AN3rC/7hwtmhrbUKO41Kw9gS90/twdgpWuR6GEimbGpl5ZxZYGhwhhcI ucvHDaXh5ek3WUvSdvF0GOD4i+ckrQar X-Received: by 10.80.134.208 with SMTP id 16mr31514596edu.67.1493940611616; Thu, 04 May 2017 16:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.159.37 with HTTP; Thu, 4 May 2017 16:29:31 -0700 (PDT) In-Reply-To: References: From: Tony Przygienda Date: Thu, 4 May 2017 16:29:31 -0700 Message-ID: To: ospf@ietf.org Content-Type: multipart/alternative; boundary=f403045c1898789542054ebb2729 Archived-At: Subject: Re: [OSPF] OSPF Digest, Vol 135, Issue 12 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 23:30:16 -0000 --f403045c1898789542054ebb2729 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A conditional -1 here ... I am fine with adoption if I see a version that spells the detailed behavior and especially interactions between RFC4302 and this draft in a detailed section, i.e. both on, RFC4302 gets configured/unconfigured, are the LLS extensions advertised on every hello or just until a specific state (like ISIS padding thingies) and so on ... I'd rather have this now than a LC discussion ... The idea is deceptively simple but it is a redundant mechanism and those always end causing inter-op problems unless cleanly spelled out ... --- tony On Thu, May 4, 2017 at 3:18 PM, wrote: > Send OSPF mailing list submissions to > ospf@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ospf > or, via email, send a message with subject or body 'help' to > ospf-request@ietf.org > > You can reach the person managing the list at > ospf-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OSPF digest..." > > Today's Topics: > > 1. Re: WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" (Les Ginsberg (ginsberg)) > 2. Re: WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" (Robert Raszuk) > 3. Re: WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" (Yingzhen Qu) > > > ---------- Forwarded message ---------- > From: "Les Ginsberg (ginsberg)" > To: "Acee Lindem (acee)" , OSPF WG List > Cc: > Bcc: > Date: Thu, 4 May 2017 21:07:14 +0000 > Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" > > A strong +1 here. > > > > Acee has captured very well the compelling(sic) reasons for defining thes= e > extensions. > > > > Use of RFC 4302 extensions are only a workaround for functionality which > is missing in the protocol. We need to close that gap. > > > > Les > > > > > > *From:* OSPF [mailto:ospf-bounces@ietf.org] *On Behalf Of *Acee Lindem > (acee) > *Sent:* Thursday, May 04, 2017 1:27 PM > *To:* OSPF WG List > *Subject:* Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" > > > > Speaking as a WG member: > > > > I believe we should move forward with this simple mechanism for OSPFv2 > neighbors to learn each other=E2=80=99s interface ID. Both IS-IS and, mor= e > importantly, OSPFv3 learn the interface ID via their respective hello > mechanisms. Just because one implementation has repurposed the Generalize= d > MPL (GMPL) extensions described in RFC 4302 for interface ID learning is > not a reason to preclude using the more generally accepted IGP Hello pack= et > learning. Additionally, there is the undesirable side effect of TE LSAs > resulting in inclusion in the TE topology for multiple implementations. > > > > Finally, when the right technical direction is clear and there is rough > consensus, the OSPF WG MUST NOT be obstructed. > > > > Thanks, > > Acee > > > > *From: *Acee Lindem > *Date: *Thursday, May 4, 2017 at 2:45 PM > *To: *OSPF WG List > *Subject: *WG Adoption Poll for "OSPF LLS Extensions for Local Interface > ID Advertisement" > > > > > > This draft was presented in Chicago and there was acknowledgment that a > solution was needed. The authors have asked for WG adoption and we are no= w > doing a WG adoption poll. Please indicate your support or objection by Ma= y > 20th, 2017. > > > > Thanks, > > Acee > > > > ---------- Forwarded message ---------- > From: Robert Raszuk > To: "Acee Lindem (acee)" > Cc: OSPF List > Bcc: > Date: Thu, 4 May 2017 17:20:29 -0400 > Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" > Support. > > On May 4, 2017 11:52 AM, "Acee Lindem (acee)" wrote: > >> >> This draft was presented in Chicago and there was acknowledgment that a >> solution was needed. The authors have asked for WG adoption and we are n= ow >> doing a WG adoption poll. Please indicate your support or objection by M= ay >> 20th, 2017. >> >> Thanks, >> Acee >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> >> > > ---------- Forwarded message ---------- > From: Yingzhen Qu > To: "Acee Lindem (acee)" , OSPF WG List > Cc: > Bcc: > Date: Thu, 4 May 2017 22:18:41 +0000 > Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" > > Strong support +1 here. > > > > The draft provides a generic way for the missing info and it=E2=80=99s ne= eded. > > > > Thanks, > > Yingzhen > > > > *From:* OSPF [mailto:ospf-bounces@ietf.org] *On Behalf Of *Acee Lindem > (acee) > *Sent:* Thursday, May 04, 2017 1:27 PM > *To:* OSPF WG List > *Subject:* Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions for Local > Interface ID Advertisement" > > > > Speaking as a WG member: > > > > I believe we should move forward with this simple mechanism for OSPFv2 > neighbors to learn each other=E2=80=99s interface ID. Both IS-IS and, mor= e > importantly, OSPFv3 learn the interface ID via their respective hello > mechanisms. Just because one implementation has repurposed the Generalize= d > MPL (GMPL) extensions described in RFC 4302 for interface ID learning is > not a reason to preclude using the more generally accepted IGP Hello pack= et > learning. Additionally, there is the undesirable side effect of TE LSAs > resulting in inclusion in the TE topology for multiple implementations. > > > > Finally, when the right technical direction is clear and there is rough > consensus, the OSPF WG MUST NOT be obstructed. > > > > Thanks, > > Acee > > > > *From: *Acee Lindem > *Date: *Thursday, May 4, 2017 at 2:45 PM > *To: *OSPF WG List > *Subject: *WG Adoption Poll for "OSPF LLS Extensions for Local Interface > ID Advertisement" > > > > > > This draft was presented in Chicago and there was acknowledgment that a > solution was needed. The authors have asked for WG adoption and we are no= w > doing a WG adoption poll. Please indicate your support or objection by Ma= y > 20th, 2017. > > > > Thanks, > > Acee > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --f403045c1898789542054ebb2729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A conditional -1 here ...=C2=A0

I am fi= ne with adoption if I see a version that spells the detailed behavior and e= specially interactions between RFC4302 and this draft in a detailed section= , i.e. both on, RFC4302 gets configured/unconfigured, are the LLS extension= s advertised on every hello or just until a specific state (like ISIS paddi= ng thingies) and so on ...=C2=A0

I'd rather ha= ve this now than a LC discussion ...=C2=A0

The ide= a is deceptively simple but it is a redundant mechanism and those always en= d causing inter-op problems unless cleanly spelled out ...=C2=A0
=
--- tony=C2=A0


On Thu, May 4, 2017 at 3:18 PM, <ospf-request@ietf.org> wrote:
Send OSPF mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ospf@ietf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/<= wbr>listinfo/ospf
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ospf-r= equest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ospf-own= er@ietf.org

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

Today's Topics:

=C2=A0 =C2=A01. Re:=C2=A0 WG Adoption Poll for "OSPF LLS Extensions fo= r Local
=C2=A0 =C2=A0 =C2=A0 Interface ID Advertisement" (Les Ginsberg (ginsbe= rg))
=C2=A0 =C2=A02. Re:=C2=A0 WG Adoption Poll for "OSPF LLS Extensions fo= r Local
=C2=A0 =C2=A0 =C2=A0 Interface ID Advertisement" (Robert Raszuk)
=C2=A0 =C2=A03. Re:=C2=A0 WG Adoption Poll for "OSPF LLS Extensions fo= r Local
=C2=A0 =C2=A0 =C2=A0 Interface ID Advertisement" (Yingzhen Qu)


---------- Forwarded message ----------
From:=C2=A0"Les Gin= sberg (ginsberg)" <ginsberg@c= isco.com>
To:=C2=A0"Acee Lindem (acee)" <acee@cisco.com>, OSPF WG List <ospf@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
D= ate:=C2=A0Thu, 4 May 2017 21:07:14 +0000
Subject:=C2=A0Re: [OSPF] WG Ado= ption Poll for "OSPF LLS Extensions for Local Interface ID Advertiseme= nt"

A str= ong +1 =C2=A0here.

=C2=A0

Acee = has captured very well the compelling(sic) reasons for defining these exten= sions.

=C2=A0

Use o= f RFC 4302 extensions are only a workaround for functionality which is miss= ing in the protocol. We need to close that gap.

=C2=A0

=C2= =A0=C2=A0 Les

=C2=A0

=C2=A0

From: OSPF [ma= ilto:ospf-bounce= s@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 04, 2017 1:27 PM
To: OSPF WG List
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions f= or Local Interface ID Advertisement"

=C2=A0

Speaking as a WG member:=

=C2=A0

I believe we should move= forward with this simple mechanism for OSPFv2 neighbors to learn each othe= r=E2=80=99s interface ID. Both IS-IS and, more importantly, OSPFv3 learn th= e interface ID via their respective hello mechanisms. Just because one implementation has repurposed the Generalized MPL (GMPL) = extensions described in RFC 4302 for interface ID learning is not a reason = to preclude using the more generally accepted IGP Hello packet learning. Ad= ditionally, there is the undesirable side effect of TE LSAs resulting in inclusion in the TE topology for multi= ple implementations.

=C2=A0

Finally, when the right = technical direction is clear and there is rough consensus, the OSPF WG MUST= NOT be obstructed.<= /u>

= =C2=A0

Thanks,

Acee =C2=A0

= =C2=A0

From= : Acee Lindem <<= a href=3D"mailto:acee@cisco.com" target=3D"_blank">acee@cisco.com> Date: Thursday, May 4, 2017 at 2:45 PM
To: OSPF WG List <ospf@ietf.org>
Subject: WG Adoption Poll for "OSPF LLS Extensions for Local In= terface ID Advertisement"

= =C2=A0

= =C2=A0

This dr= aft was presented in Chicago and there was acknowledgment that a solution w= as needed. The authors have asked for WG adoption and we are now doing a WG= adoption poll. Please indicate your support or objection by May 20th, 2017.=C2=A0

= =C2=A0

Thanks,=

Acee=C2= =A0



---------- Forwarded message ----------
From:=C2=A0Robert Raszuk= <robert@raszuk.net>
To:= =C2=A0"Acee Lindem (acee)" <= acee@cisco.com>
Cc:=C2=A0OSPF List <ospf@ietf.org>
Bcc:=C2=A0
Date:=C2=A0Thu, 4 May 2017 17= :20:29 -0400
Subject:=C2=A0Re: [OSPF] WG Adoption Poll for "OSPF LL= S Extensions for Local Interface ID Advertisement"
Support.

O= n May 4, 2017 11:52 AM, "Acee Lindem (acee)" <acee@cisco.com> wrote:

This draft was presented in Chicago and there was acknowledgment that = a solution was needed. The authors have asked for WG adoption and we are no= w doing a WG adoption poll. Please indicate your support or objection by Ma= y 20th, 2017.=C2=A0

Thanks,
Acee=C2=A0

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf



---------- Forwarded message ----------
From:=C2=A0Yingzhen Qu &= lt;yingzhen.qu@huawei.com>=
To:=C2=A0"Acee Lindem (acee)" <acee@cisco.com>, OSPF WG List <ospf@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Thu, 4= May 2017 22:18:41 +0000
Subject:=C2=A0Re: [OSPF] WG Adoption Poll for &= quot;OSPF LLS Extensions for Local Interface ID Advertisement"

Stron= g support +1 here.

=C2=A0

The d= raft provides a generic way for the missing info and it=E2=80=99s needed.

=C2=A0

Thank= s,

Yingz= hen

=C2=A0

From:= OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 04, 2017 1:27 PM
To: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] WG Adoption Poll for "OSPF LLS Extensions f= or Local Interface ID Advertisement"

=C2=A0

Speaking as a WG member:=

=C2=A0

I believe we should move= forward with this simple mechanism for OSPFv2 neighbors to learn each othe= r=E2=80=99s interface ID. Both IS-IS and, more importantly, OSPFv3 learn th= e interface ID via their respective hello mechanisms. Just because one implementation has repurposed the Generalized MPL (GMPL) = extensions described in RFC 4302 for interface ID learning is not a reason = to preclude using the more generally accepted IGP Hello packet learning. Ad= ditionally, there is the undesirable side effect of TE LSAs resulting in inclusion in the TE topology for multi= ple implementations.

=C2=A0

Finally, when the right = technical direction is clear and there is rough consensus, the OSPF WG MUST= NOT be obstructed.<= /u>

= =C2=A0

Thanks,

Acee =C2=A0

= =C2=A0

From= : Acee Lindem <<= /span>acee@cisco.com>
Date: Thursday, May 4, 2017 at 2:45 PM
To: OSPF WG List <ospf@ietf.org>
Subject: WG Adoption Poll for "OSPF LLS Extensions for Local In= terface ID Advertisement"

= =C2=A0

= =C2=A0

This dr= aft was presented in Chicago and there was acknowledgment that a solution w= as needed. The authors have asked for WG adoption and we are now doing a WG= adoption poll. Please indicate your support or objection by May 20th, 2017.=C2=A0

= =C2=A0

Thanks,=

Acee=C2= =A0


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf




--
=
We=E2=80=99ve heard that a million monkeys at a million keyboards c= ould produce the complete works of Shakespeare; now, thanks to the Internet= , we know that is not true.
= =E2=80=94Robert Wilensky
--f403045c1898789542054ebb2729--