Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
Andy Bierman <andy@yumaworks.com> Mon, 11 April 2022 17:28 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 710ED3A0029 for <netmod@ietfa.amsl.com>; Mon, 11 Apr 2022 10:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, 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 5sj69Rl4fLBF for <netmod@ietfa.amsl.com>; Mon, 11 Apr 2022 10:28:27 -0700 (PDT)
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (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 D243D3A110B for <netmod@ietf.org>; Mon, 11 Apr 2022 10:28:26 -0700 (PDT)
Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-2ebdf6ebd29so102997797b3.2 for <netmod@ietf.org>; Mon, 11 Apr 2022 10:28:26 -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=GhfkPg02BeFfzg/FnOVeu8UeJrqSMlf4v53mzAxiDmc=; b=lpOX5WMeOt/oVRpO5Pa/855WbQXgYKPsAUbGZgQrWgRkxsXt3Sx5UyBRo3fnh/HTws qWaeZRNZa4CjjmUo6Ea1xnljax2hqGlvTr/fUGhnc2+J+AOHojK4Zjp4W5bJVzjStSYc spoPPrtOhXA5v2Vho7tys9701rLoKj2m0EvSftclZqfBwTW3ItV+BBqbfMnOj1BEUnbs TETJm1Wk4E7LRAnRUKU1Z8pf22aQNtmH/1W0KLG6BB/7ooRsgBWPGjvY7cjhZQ6LpdVJ jdSC/BrWdPTYp0969QvfM6YXR/vMNb2LRNH28y9Kax6uF/LyXl4oWdWgN5s+rwDtV1yv t4cg==
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=GhfkPg02BeFfzg/FnOVeu8UeJrqSMlf4v53mzAxiDmc=; b=RoWGn+LVpNBn76hOnWivhmNdv1ruQd46/+esD/boSL9n2sW0KA6Zg+7iSVO08cQ66j cZcWIYltdGsNdDtB+SCUEfYrV3HoQz+9WfL5Dssa3Wp72BIKqBlZPcsQRdW5xkUEHQm8 fLFehyotE7uHpz1aTpxQWBwmpigv9Okl+p6emVEUwkQna+sg5fNAS4hCtC9auSffxS26 kXYTwYfUYc9HS2Ra3veeeOF+T0LMznYhJfmRaqVu0ls4hdo3gX39YeLnmuYDOh/fuKZi LXokdsIpShKsKsdKsFUl+CY2R64erNrkWtk+xc5kNyN2glLsSj3qUmB003BbEetoSjDs 4uRA==
X-Gm-Message-State: AOAM532/SsCcJPXAV7TJbE7itk8nXYqu1/d+uNA2kzK5M4mpsIbQZ9kY QIKB+ImW+3Mio5JSlJ2wvYzF+B+7b3tnTZTez8rjfGXwcFM=
X-Google-Smtp-Source: ABdhPJyU+PFBXlBR2rJZsnYtVg4n3QYAPQ5IyCxwPXCX4cMHj5NgEloz5koSAE7VE6hZRiJcjwZOi5FI/6n8HmTfVDY=
X-Received: by 2002:a81:5dd6:0:b0:2d6:3041:12e0 with SMTP id r205-20020a815dd6000000b002d6304112e0mr27292910ywb.331.1649698105608; Mon, 11 Apr 2022 10:28:25 -0700 (PDT)
MIME-Version: 1.0
References: <164662287026.10186.17661147788695088858@ietfa.amsl.com> <AM7PR07MB62483353E387A0538EDA44C6A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <AM7PR07MB6248D0B4D19EF3168DEC4864A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <978D3500-5A9C-49FA-A259-B4E234CC9332@cisco.com> <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> <3F7DDA02-DEFA-4680-B048-1AB0A54C2FA1@chopps.org> <BB1D53D0-0D36-40DF-8B9D-4BD4EB6A35C1@cisco.com> <5b05a34d-41b6-7b65-ebe7-9dcaca80eeb2@alumni.stanford.edu> <m2wnfzydgz.fsf@ja.int.chopps.org> <530e30e1-9436-2123-7d03-eb4f876a9f90@alumni.stanford.edu> <BY5PR11MB4196F5F342BA12E79FF29B08B5EA9@BY5PR11MB4196.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4196F5F342BA12E79FF29B08B5EA9@BY5PR11MB4196.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 11 Apr 2022 10:28:14 -0700
Message-ID: <CABCOCHS+uLjK5GcpCrmegCWBHoK=1-ySZhqO+D-TEnyGUki5kQ@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000925ee505dc644525"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hn_yLFXsZQi_XqCkYxoH8kZRmKE>
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: Mon, 11 Apr 2022 17:28:32 -0000
On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) <rwilton= 40cisco.com@dmarc.ietf.org> wrote: > Hi all, > > Thanks for the comments on this thread so far. It would be nice if we are > able to come to some sort of rough consensus to a solution. > > I think that there is consensus that the YANG type ip-address (and the > v4/v6 versions) are badly named as the prominent default type name has been > given to the unusual variant of including zone information. > > Based on the comments on this thread, it also seems likely to me that most > of the usages of ip-address in YANG RFCs is likely to be wrong, and the > intention was that IP addresses without zones was intended. At a rough > count, of the published RFC YANG models at github > YangModels/standard/ietf/RFC/ to be: > 86 uses of ip-address > 68 uses of ipv4-address > 66 uses of ipv6-address > > 1 use of ip-address-no-zone > 4 uses of ipv4-address-no-zone > 4 uses of ipv6-address-no-zone > > These types appear in 49 out of the 141 YANG modules published in RFCs. > At a quick guess/check it looks like these 49 YANG modules may appear in > 40-50 RFCs. > > As mentioned previously, it is also worth comparing this to the OpenConfig > YANG modules: > They have redefined ip-address (and v4/v6 variants) to exclude zone > information and have defined separate types include zone information. > There are no explicit uses of the "-zoned" variants of OpenConfig IP > addresses in the latest OpenConfig github repository. However, > approximately a third of the IP address types are still to the > ietf-inet-types.yang rather than openconfig-inet-types.yang, so in theory > some of those 58 entries could still intentionally be supporting zoned IP > addresses, but I would expect that the vast majority would not. > I do see some strong benefit if this basic type being defined in the same > way in both IETF and OC YANG, and I believe that the OC folks have got the > definition right. > > I see that some are arguing that the zone in the ip-address definition is > effectively optional, and implementations are not really obliged to > implement it. I don't find that argument compelling, at least not with the > current definition of ip-address in RFC 6991. I see a clear difference > between a type defined with an incomplete regex that may allow some invalid > values and a type that is explicitly defined to included additional values > in the allowable value space. Further, I believe that a client just > looking at the YANG module could reasonably expect a server that implements > a data node using ip-address would be expected to support IP zones, where > they are meaningful, or otherwise they should deviate that data node to > indicate that they don't conform to the model. > > We also need to be realistic as to what implementations will do. They are > not going to start writing code to support zones just because they are in > the model. They will mostly reject IP addresses with zone information. > Perhaps some will deviate the type to ip-address-no-zone, but probably most > won't. > > The option of respinning approx. 40-50 RFCs to fix this doesn't feel at > all appealing. This would take a significant amount of time/effort and I > think that we will struggle to find folks who are willing to do this. > Although errata could be used to point out the bug, then can't be used to > fix it, all the errata would be "hold for document update" at best. > Further, during the time that it would take us to fix it, it is plausible > that more incorrect usages of ip-address will likely occur (but perhaps > could be policed via scripted checks/warnings). > > > I still feel the right long-term solution here is to get to a state where > the "ip-address" type means what 99% of people expect it to mean, i.e., > excluding zone information. > > Given the pushback on making a single non-backwards compatible change to > the new definition, I want to ask whether the following might be a possible > path that gains wider consensus: > > (1) In RFC 6991 bis, I propose that we: > (i) define new ip-address-with-zone types (and v4 and v6 versions) and > keep the -no-zone versions. > (ii) we change the description of "ip-address" to indicate: > - Although the type allows for zone information, many implementations are > unlikely to accept zone information in most scenarios (i.e., so the > description of the type more accurately reflects reality). > - A new ip-address-with-zone type has been introduced to use where zoned > IP addresses are required/useful, and models that use ip-address with the > intention of supporting zoned IP addresses MUST migrate to > ip-address-with-zone. > - In the future (at least 2 years after RFC 6991 bis is published), the > expectation is that the definition of ip-address will change to match that > of ip-address-no-zone. > > (2) Then in 2 years time, we publish RFC 6991-bis-bis to change the > definition of ip-address to match ip-address-no-zone and deprecate the > "-no-zone" version at the same time. > > My reasoning as to why to take this path is: > (1) It is a phased migration, nothing breaks, 3rd parties have time to > migrate. > (2) It ends up with the right definition (with the added bonus that it > aligns to the OC definition). > (3) It doesn't require us republishing 40+ RFCs. > (4) it hopefully allows us to use YANG versioning to flag this as an NBC > change, along with the other standards to help mitigate this change (import > revision-or-derived, YANG packages, schema comparison). > > I would be keen to hear thoughts on whether this could be a workable > consensus solution - i.e., specifically, you would be able to live with it. > > This is a very thoughtful proposal. Looks good to me. It does introduce a window in which some new modules might start using 'ip-address-no-zone'. Should they wait for the real 'ip-address' in 2 more years or just use 'ip-address-no-zone'? The leaf description-stmt using 'ip-address' should specify if any zone support is required. The default could be 'none' so no mention is needed most of the time. > Regards, > Rob > > > Andy > > > -----Original Message----- > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Randy Presuhn > > Sent: 08 April 2022 18:59 > > To: Christian Hopps <chopps@chopps.org> > > Cc: lsr@ietf.org; netmod@ietf.org > > Subject: Re: [netmod] [Lsr] I-D Action: > draft-ietf-lsr-ospfv3-extended-lsa- > > yang-10.txt > > > > Hi - > > > > On 2022-04-08 5:11 AM, Christian Hopps wrote: > > .. > > > Instead, Acee (I'm not sure I'd call him WG B :) is asserting that > > > *nobody* actually wanted the current type, and it has been misused > > > everywhere and all over. The vast majority of implementations in > > > operation probably can't even handle the actual type (Andy's point). > So, > > > Acee is just the messenger of bad news here. Please note that the AD in > > > charge of all this agreed with Acee as well. > > > > That's not the impression one gets from modules like > > https://www.ietf.org/archive/id/draft-ietf-mpls-mldp-yang-10.txt > > which employs both types. So, regardless of whether one is willing > > to respect YANG's compatibility rules, it's no longer a matter of > > speculation whether a name change would cause actual damage - > > it clearly would. Furthermore, my recollection is that the > > WG *did* discuss whether the "zonable" property was needed, so > > any argument based on the assertion that "*nobody* actually > > wanted the current type" seems to me to based on a false premise. > > > > Randy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > 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… 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… 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… 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