Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
Andy Bierman <andy@yumaworks.com> Thu, 07 April 2022 16:31 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894823A0F0A for <netmod@ietfa.amsl.com>; Thu, 7 Apr 2022 09:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.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 Sh66bJK9mPo7 for <netmod@ietfa.amsl.com>; Thu, 7 Apr 2022 09:31:54 -0700 (PDT)
Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com [IPv6:2607:f8b0:4864:20::112e]) (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 4083F3A16A9 for <netmod@ietf.org>; Thu, 7 Apr 2022 09:31:38 -0700 (PDT)
Received: by mail-yw1-x112e.google.com with SMTP id 00721157ae682-2eba37104a2so68549817b3.0 for <netmod@ietf.org>; Thu, 07 Apr 2022 09:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q27kBRopxARHg9NSlcmtHNdidOvEXwayeWO50ft9pdQ=; b=edFHNhZ9ml4j//e39f/Qp7o3bQxFuXqouo0MyiguyO1xtQQGmMd/1ECsKpvDKef41n u2mcst9iqUYxiRnGDGyZAdcgdJvbWAUZq4LmPC9nS6uNxka3FroB4299zM9r6GZO0BkI 7z7yaVE3kvqm9t9kUq5x1cVxRO/279bcGsboQmfH2oxW0IHwtVdz6QMnAAp3PFEOXZB5 oKRmZOjinPkT5RvWsxoO8oEgVM2AcbBIzUNHkzLhnarY5zkXWR0N01FmAXpDtgqt93c+ R9MMNhPtbQslh/fwQ2JhVCgIYSCAFdl+YzTmladKH7H18BNoFUlgjQv4qscV6UcNnAMT t+VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q27kBRopxARHg9NSlcmtHNdidOvEXwayeWO50ft9pdQ=; b=MZpUOzLwOCCEpQk4HSyh+GZmYyT4WeeBqnfY9TWVMmugHPF7Eif/19M9hEMBkyR/Dg XAGmkB0XclIaqILY86Ew9USfU6wTpnEfvfrv0PzCGOw5Et27QsHG+XUyZF1gyU9txIQz bGVlXQwqRreI8kyroMS0CLdBl4k9RR+T4cbOdELla1C0VjKGuCwVz1Qpbpil3ESxmjHn 1sFcQCkUt511HSXXt/JzK6yFgXcEf1dnRlYdOqgYduBIb49j/TvaSiVH0y/RxZUObMfx f98zLOnpoEtJvb7cqs0uoQrL7/bPpIW/KAOiuvHGA8KMt/C8XAuNOpBmWx4jaxlooiu1 kGOw==
X-Gm-Message-State: AOAM530QW5cX7ngJiT2q40kfzGPLfyEhc5aWHACj87l8UjMm9xN4oxgK OBHf3Q+l0NI2UoAnpP+kz0/QWl+xeSmLksIQ7c7iauxAMys=
X-Google-Smtp-Source: ABdhPJwjR/fHaGOx3M46gEHIJTHyifvNbBBdw+k6N4rmgLe8HdXMNQuqS+oyAg/M8QcOonx+s84henkR/5/ZCC4zxes=
X-Received: by 2002:a0d:dbce:0:b0:2eb:754e:e223 with SMTP id d197-20020a0ddbce000000b002eb754ee223mr11934363ywe.350.1649349096937; Thu, 07 Apr 2022 09:31:36 -0700 (PDT)
MIME-Version: 1.0
References: <AM7PR07MB6248CE4BDC0B27008D4F04BCA0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <2C00E058-F836-415E-A357-797E01FE77AD@cisco.com> <DB7E3112-3C2F-4040-81E1-F4625689DA62@chopps.org> <645FCC0B-8279-4070-B052-A553317B8474@cisco.com> <20220405153644.w5faspao6qkbq337@anna> <B98C7C87-D7B6-4DB0-85C7-E8B61EDC66F6@cisco.com> <CABCOCHTZC+HqgBWr=m_wvVdgbDFnR6kTTv-XB20Ujn8uhj6krQ@mail.gmail.com> <20220405190249.chscwo4m4v4l5xoj@anna> <CABCOCHQ17cQz1sM3iWLpmnOrrLR_V9r8qipckhaEb5ouW0YdEg@mail.gmail.com> <E95B1413-1363-4BD6-A23B-141FAA640C00@cisco.com> <20220407073452.rslzcxakaqnojedr@anna> <BY5PR11MB419642B5948BC3E96366465FB5E69@BY5PR11MB4196.namprd11.prod.outlook.com> <AM7PR07MB624847EE93F8A9405F2C6965A0E69@AM7PR07MB6248.eurprd07.prod.outlook.com>
In-Reply-To: <AM7PR07MB624847EE93F8A9405F2C6965A0E69@AM7PR07MB6248.eurprd07.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 07 Apr 2022 09:31:26 -0700
Message-ID: <CABCOCHS59ZxUYLhJsSCWE_TNcTHtjzYzh-2KpUyswrk_1TQjuQ@mail.gmail.com>
To: tom petch <ietfc@btconnect.com>
Cc: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>, "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000008b8ab05dc1303de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/G69AC3x-peU6fJd72I-ejRZP1Jo>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2022 16:32:00 -0000
On Thu, Apr 7, 2022 at 9:11 AM tom petch <ietfc@btconnect.com> wrote: > From: Lsr <lsr-bounces@ietf.org> on behalf of Rob Wilton (rwilton) > <rwilton=40cisco.com@dmarc.ietf.org> > Sent: 07 April 2022 10:25 > > I basically agree with Acee, and I think that we should do (b): > > b) Change the types as suggested and accept that doing so breaks > modules where zone indexes are meaningful. > > <tp> > > I am concerned that such behaviour will damage the standing of the IETF at > large. > > MAY for the client means MUST for the server. But if no servers actually support it, because the YANG does not match the operational requirements, then is it really a MUST requirement? This seems like a bugfix, and the worst thing the IETF could do wrt/ standing is to force the world to change every module that imports the typedef. Since many people were not aware of the full syntax, it is not clear that the WG intent was to include a zone. Seems like a bugfix to a pattern, like we have done several times already. Andy > We clearly laid down rules as to what updates were regarded as compatible > so that authors of software could be confident that their work was robust > and future-proof. We did it with SNMP, inter alia, and we have carried > that forward with YANG. To tear up that understanding , creating who knows > how much disruption, can only harm the standing of IETF. > > Much has been said about how implementations have assumed that the address > types do not include a zone but no evidence has been put forward for that > assertion. > > I have always assumed that software uses libraries and that the libraries > have been written with an understanding of the specifications such that if > a zone is received over the wire in conformance with the specification but > where the display, field or such like does not allow for a zone, then, > tolerant of what to accept, the zone is silently discarded and the address > is used without the zone. But, like the assertion that keeping the zone > will cause who knows what damage, I have not done the research to > substantiate that assumption. > > Tom Petch > > I appreciate that this is an NBC change, but I believe that this is the > most intuitive definition and is the best choice longer term. I also note > that the base ipv4-address/ipv6-address types in OpenConfig (where they use > the OC copy/version of inet-types and not ietf-inet-types) don't allow a > zone to be specified and assumes the default zone. They have separate > types in cases where a zone is allowed to be specified, i.e., aligned to > what (b) proposes. > > For modules that are using/wanting zones (if any), then they can migrate > to the new explicit zone type. draft-ietf-netmod-yang-module-versioning, > if it keeps its import "revision-or-derived" extension, would also allow > such modules to indicate the dependency on the updated revision/definition > of ietf-inet-types.yang. > > Of course, the description associated with the updated > ietf-inet-types.yang revision should clearly highly the > non-backwards-compatible change to the types. > > Rob > > > -----Original Message----- > From: iesg <iesg-bounces@ietf.org> On Behalf Of Jürgen Schönwälder > Sent: 07 April 2022 08:35 > To: Acee Lindem (acee) <acee@cisco.com> > Cc: lsr@ietf.org; The IESG <iesg@ietf.org>; netmod@ietf.org > Subject: Re: [netmod] [Lsr] I-D Action: > draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt > > Here is roughly what happened: > > - RFC 6020 (published ~12 years ago) introduced the ip-address > type. It included an optional zone index part since zone indexes > are necessary in certain situations (e.g., configuring services > listening on link-local addresses or clients connecting to services > listening on link-local addresses). > > - RFC 6991 (published ~9 years ago) added the ip-address-no-zone types > since people felt that it is useful to also an ip address type > without the optional zone part for situations where a zone is not > applicable. The name 'ip-address-no-zone' was picked since the name > ip-address was already taken. > > I understand that the names resulting from this evolution of the YANG > module confuse people not looking up the type definitions. Let me note > that using a type allowing for an optional zone for a leaf that never > needs a zone is not a fatal error (its like using an int where a short > is sufficient) while using a type not allowing for a zone for a leaf > that may need zones is a fatal error (using a short where an int is > required) requiring an update of the definition of the leaf to fix. > > What are our options? > > a) Do nothing and accept that types are called as they are. > b) Change the types as suggested and accept that doing so breaks > modules where zone indexes are meaningful. > c) Deprecate the types and create a new module defining new types > so that modules can opt-in to use better names. > d) Deprecate the -no-zone types and move back to have a single > type for IP addresses. > > Any other options? > > How are we going to pick between them? > > /js > > On Wed, Apr 06, 2022 at 09:02:23PM +0000, Acee Lindem (acee) wrote: > > Jürgen and netmod WG, +IESG, > > > > It is not just the IETF models that are using the inet:ip-address for > the standard IPv4/IPv6 addresses without zones. Every vendor’s native > models and the OpenConfig models use the base types and expect the standard > IP address notation. If we don’t fix this, it is something that people can > point to as another example of the IETF being out of touch with reality. > > > > I thought about more, and it might make the backward compatibility > easier if we just leave the existing ip-address-no-zone, > ipv4-address-no-zone, and ipv6-address-no-zone types and add *-zone types > for the remote possibility that someone actually wants to include the > zone. In the existing RFC 6991 BIS document, we could merely remove the > zone from the ip-address, ipv4-address, and ipv6-address types and classify > this as we would any other bug fix. While including the zone was the > original intent of the base types, this is what those of us who work on > software products would classify as a requirements bug. > > > > Thanks, > > Acee > > > > From: Andy Bierman <andy@yumaworks.com> > > Date: Tuesday, April 5, 2022 at 3:21 PM > > To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy > Bierman <andy@yumaworks.com>, Acee Lindem <acee@cisco.com>, "lsr@ietf.org" > <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org> > > Subject: Re: [netmod] [Lsr] I-D Action: > draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt > > > > > > > > On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder < > j.schoenwaelder@jacobs-university.de<mailto: > j.schoenwaelder@jacobs-university.de>> wrote: > > On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote: > > > > > > > > The best outcome would be to fix ip-address to not include the zone, > > > > introduce ip-address-zone, and deprecate ip-address-no-zone. My take > all > > > > the is that all the existing usages do not require zone and this > would be a > > > > fix as opposed to a change. > > > > > > > > > > > I don't think this will harm our implementations. > > > The type is still string. The pattern will change but that is handled > by a > > > library. > > > Whatever pattern is used will get handled the same way. > > > > Either a zone is allowed to be present or it is not, this does make a > > difference, its not a cosmetic change. > > > > > > True. The code will probably accept the pattern then fail trying to use > the string. > > If the client sends the form with a zone. > > > > > > > > > > > The same problem exists for 'date' and 'date-no-zone' types, > > > but they are not used very much. > > > > Perhaps we should call types a, b, c, and so on - this may force > > people to read the descriptions. ;-) > > > > For some reason, the smarter the person, the less likely they are to > > read any of the documentation before using some software. > > I call it the "it should work the way I would design it" phenomenon :-) > > > > You have to admit that Acee's suggestion is more intuitive than the > current > > definitions. > > > > Clearly an NBC change. > > IMO it is more useful to put some YANG extension magic in these specific > typedefs > > than just bumping a major revision number. This is a great use-case for > the version DT. > > > > There probably is no solution path where nobody has to change any YANG > or any code > > and everything still works. > > > > > > > > /js > > > > Andy > > > > -- > > Jürgen Schönwälder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > -- > Jürgen Schönwälder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Kent Watsen
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Reshad Rahman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Reshad Rahman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Yingzhen Qu
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Kent Watsen
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Charles Eckel (eckelcu)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Martin Björklund
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Acee Lindem (acee)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Joel M. Halpern
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Jürgen Schönwälder
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… tom petch
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Rob Wilton (rwilton)
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Christian Hopps
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Randy Presuhn
- Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-osp… Andy Bierman