Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
Andy Bierman <andy@yumaworks.com> Tue, 12 April 2022 08:54 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 7BA1F3A0E04 for <netmod@ietfa.amsl.com>; Tue, 12 Apr 2022 01:54:32 -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 Axg2roIsRXxW for <netmod@ietfa.amsl.com>; Tue, 12 Apr 2022 01:54:27 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 23F6A3A0DF9 for <netmod@ietf.org>; Tue, 12 Apr 2022 01:54:27 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id q19so931585ybd.6 for <netmod@ietf.org>; Tue, 12 Apr 2022 01:54:27 -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=wIizaU9XmwEa18jcVOvhXRXbwFde07ecif4QyQ97eqU=; b=j1a1gXmhUS0O235w+8LRWQvNX2J/9YK20ReWqS5iwth365SbcONsOfVzEzTVn2R2SP kzbJ1THwckHNJKDwfEQok6PKlfOYRpHnTrWRVyP/z9yqAIPISI/vKnGgef4F83XJxH+i oVsNHVoJybwDJGX4R6Yra/RTgfaQi41IGdimf7xYZtNX2A7p60qZGog2nZJbivp7Aycz HUDp6YbItvySNA5NzgMijzrWa5D2PYBQF7Ic9TfePmVn6D7ZKjF6PvhomBuxlfVNB38/ c2L77Ectn5Sa/GPeL25upIuZjtlIAi4j17YqdozRszlkyPAUgg7IAX50gXKpP09S4GqZ dEUQ==
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=wIizaU9XmwEa18jcVOvhXRXbwFde07ecif4QyQ97eqU=; b=HCO9FP6TjT242K7nmuLRbKTg2aRcQODXFFDg+4teFXUoiP1UzMxcXMeLXNRO+OKXBU uprdl3MtuEJurzSiQreToIk69aBRqPqH25JWkeHajugMpqmiKXxu2hvtpcv6/N40lYvX QMLjGWHvwRtAKEAMNIiFDi/K92/Ulb2Xr41m0EFXTxHKWaCMVyeFInzaD/3Jc9PZSPo1 qj79hhlnp3x/L2MUCo/XKoDbUSVKczyMrSReup43Z4asBwA/tBTcfXaxfBtXJ0QbloPA XNMQpVGvEPvt7tN90tx3hVZF+oeJCbe5h8zlVo0wRQC5Ub6DaQjcth7XcbV1sebCG4Ly wOtA==
X-Gm-Message-State: AOAM5317OBiTwsWnXrUuYhsA1SdQD2R3jgYXC8eW/zr8J30aS1C2EEBi dEOHeN1/Om7NB5p+FOb03or+lyBUX/PJy9bvqiW23Pub3fc=
X-Google-Smtp-Source: ABdhPJxZPLJnxis/mW4asb+41GIcyziHIXndVsYubfjHoeB+z6KODuI6Rp6TAh7aml3D0F++SMsnAAjx0bVaKDKJNWI=
X-Received: by 2002:a5b:842:0:b0:633:75b6:4129 with SMTP id v2-20020a5b0842000000b0063375b64129mr26881797ybq.64.1649753665709; Tue, 12 Apr 2022 01:54:25 -0700 (PDT)
MIME-Version: 1.0
References: <m2wnfzydgz.fsf@ja.int.chopps.org> <530e30e1-9436-2123-7d03-eb4f876a9f90@alumni.stanford.edu> <BY5PR11MB4196F5F342BA12E79FF29B08B5EA9@BY5PR11MB4196.namprd11.prod.outlook.com> <20220412.092537.1752383485754368549.id@4668.se>
In-Reply-To: <20220412.092537.1752383485754368549.id@4668.se>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 12 Apr 2022 01:54:14 -0700
Message-ID: <CABCOCHTcvO-0dz5Wv==QzbaMKktJ92UF_TW58XmszLBYmhE24g@mail.gmail.com>
To: Martin Björklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>, lsr@ietf.org, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000363f0a05dc7135db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cfn621lcsIGX5rYF8ehAY0B7lB0>
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: Tue, 12 Apr 2022 08:54:33 -0000
On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund <mbj+ietf@4668.se> wrote: > Hi, > > Here's another suggestion. We keep the ip-address pattern as is, but > document in the description that implementations do not have to > support the optional zone index. This would essentially document the > behavior of most current implementations. (This is actually what I > suggested in the earliest thread on this topic that I could find: > https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-fRb2hVsf4sPuCU) > > > The point of the 2 year warning is to allow anybody using ip-address and really wants a zone index to move to the (new) ip-address-with-zone typedef instead. It has yet to be shown that this subset is not empty. This is better than making an NBC change with no warning. If people did not bother to read the typedef, why would they read the warning? This is also true, but no different than C programmers who ignore gcc warnings. Is the NBC change needed at all? Maybe not. It would be better in the long term to align with OpenConfig and with 99 - 100% of the implementations. The standards are a means to an end. Nothing more. If 99 - 100% of the implementations are already doing what is needed, then it would be a bad idea to disrupt that for the sake of standards purity. > /martin > Andy > > > "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. > > > > Regards, > > Rob > > > > > > > > > -----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 > > _______________________________________________ > 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