Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 01 April 2020 17:57 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C5C3A14AD; Wed, 1 Apr 2020 10:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NSjJs70W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=srA0ZhmV
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 dfYRjT8schHF; Wed, 1 Apr 2020 10:57:33 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5B83A14AE; Wed, 1 Apr 2020 10:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14234; q=dns/txt; s=iport; t=1585763853; x=1586973453; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T+EQ90kuZbDxzfn6e4DNGrEDfaVkp0FPj31g2CdL5dE=; b=NSjJs70Wf/thcopc0aWwrE61IxnTTjZBu8TQ9ODG17WfxSgTTqNnG2Ni jzloc8A9T9keWTBmkuxUDcTsFrwU9vRtozv09HYI+KzccqdF0ABgAvIiW szdMNsDTUKCKzgd4xDeNwjmiSUpRyBApH3c9XnJP9mCMXMDvCaIDyDFRd 4=;
IronPort-PHdr: 9a23:zyAcyRcg/cJxmNhVX80pq9eulGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/ZDQ7E8JLSFZN9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CYBQCX1YRe/49dJa1gBhwBAQEBAQcBAREBBAQBAYF7gVRQBYFEIAQLKgqEEINFA4pvgjolmB2CUgNUCgEBAQwBAS0CBAEBhEQCF4IhJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAgESEREMAQE3AQQLAgEGAhoCJgICAjAVEAEBBA4FIoMEgkwDDiABkyqQZwKBOYhidYEygn8BAQWFKRiCDAmBDiqJZYJMGoFBP4EQAScMFIFPfj6EPg8YgnsygiyOBzWCSIYiigqPVAqCPY1EiVwdgkyNDIwakHmXB4M1AgQCBAUCDgEBBYFpIoFYcBU7KgGCQT4SGA2OHYNzilV0gSmMfAGBDwEB
X-IronPort-AV: E=Sophos;i="5.72,332,1580774400"; d="scan'208";a="456578777"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2020 17:57:32 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 031HvWbi023434 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Apr 2020 17:57:32 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 12:57:32 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 13:57:31 -0400
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Apr 2020 12:57:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hjc811mn+pLdrZrgzYnGKA7QYZQYrVmbrVmIe9+hVgdkMUO7VF7A9MHakBdZf5JcW/DSaLl0qkaeMdBf3kGyiBy+eBBmsvmtCfRiEPQ262jpafwogA2sZdcwiMycV8eQ09ZAmp2hUuITBMFzp11K9ajP/M8WaD2PQTDdIFCKG91s/pH7IHn/ZFs299jtTkXnXcni01YBAPxDElYKMYPPLmC/sRft0xhLwOU1dVnw1P4TTL6iQOvkDi26VHf8P0/JKceCt2eKQUxXgM+NHeLaSu4Bgeokzga4W5iJoATjRlZLnCKTv2qnAagYAayoljfFCTsAWuefIBTqlKmS+TWLBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T+EQ90kuZbDxzfn6e4DNGrEDfaVkp0FPj31g2CdL5dE=; b=jO5/cXSWCJ53zFXcX88ffgAiUXRGAhmRInZVg01TxJbDsBp613SOAHj2We8eJdah6wUQhXt+Mgyg1bdtqqLEzQVb0HStXnuRmtIRkCcm/2Gcz4i+jwbtNBXfNDCTCRNbo+TY9XqmwWXoFZsxPwQNECQTEmYkW7EALHNPgTNfdC0MpekMisqR3KmiUPnEyzkmrWW+68L01lSw/ABgSE6n6Hx1tJds7X8OzhhgJ7VZ3ZnTUtnNjGbobmvs/Av4HG9IJ7RcEtu24TtMxVNQW3pM9dg8Cjvob6/izDcSuw1Xjax1/yo975CeauwYrAxGpCEtvbyiOclxf9386AJKemzfYw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T+EQ90kuZbDxzfn6e4DNGrEDfaVkp0FPj31g2CdL5dE=; b=srA0ZhmViNdHoa2psQCgie5OmNug6SIeuSqyqWVwAIFYnDku5Q/3KUV6S2zzrVGH0e9iqi2aSM0i5ufVhuiMM8fQ6P6ESpmSnP4tef+xVTYSxTevEwzKIRZUKFNAnZDhUQqipTy3hEcK47Zzsq2FvWVSGRiuls74TYX7MziMGnY=
Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3843.namprd11.prod.outlook.com (2603:10b6:408:88::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Wed, 1 Apr 2020 17:57:30 +0000
Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74%7]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 17:57:30 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Adrian Farrel <adrian@olddog.co.uk>
CC: "draft-ietf-mpls-lsp-ping-registries-update@ietf.org" <draft-ietf-mpls-lsp-ping-registries-update@ietf.org>, mpls <mpls@ietf.org>
Thread-Topic: Review of draft-ietf-mpls-lsp-ping-registries-update-01
Thread-Index: AdYIR9J7mClFBWOaQoqHGGT02ONvpAABy9UA
Date: Wed, 01 Apr 2020 17:57:30 +0000
Message-ID: <C56BE1EF-230A-4430-BAEF-6453F99D22BA@cisco.com>
References: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk>
In-Reply-To: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.80.23.2.2)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com;
x-originating-ip: [108.203.7.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0468f2db-54c4-4cd7-0246-08d7d6662591
x-ms-traffictypediagnostic: BN8PR11MB3843:
x-microsoft-antispam-prvs: <BN8PR11MB3843C65022A29D021BE636DDC7C90@BN8PR11MB3843.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(396003)(39860400002)(366004)(136003)(6916009)(26005)(81156014)(2616005)(5660300002)(91956017)(2906002)(186003)(8676002)(81166006)(8936002)(76116006)(36756003)(66946007)(66476007)(86362001)(6486002)(6506007)(15650500001)(33656002)(478600001)(71200400001)(66446008)(4326008)(64756008)(66556008)(316002)(54906003)(6512007); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EsH317/S5qz8S0lvhZpL2I99YH7DyIiw7XmEHTAlI6X27iHSXusB1gdsupO8EtnqtnY/mpEuSfLIM/oMbXg5YjENQtbYsfPWdRJ4FfSgTRAaCyHHzhW49/7EPCf278hJRJakKH9FL2vyN1GuP0XnOp6uoCoDVbOmFcvwFGgnoQsffmpanN2Fy07SU39meVSu4ni919vzebyXDfYGTc/oGUfIxSA1sEUDx3FsmRFxayd5b0LZwlssqTjCoXHVSZBxFBls17GTVFdGmr1rz2AuwoaF8wn1ihF8lxxciqgn6dhEjBYSwLUJ43HvWWDJUlsDRl5p1pUO3BqE4FT3Js2VVHgyC2U5JRnuvexkemflMUGo8GBnpOB3idTJsoYHt7Uy7pMAIQa6T5ejHdx+GhVup7r1d704QX8qEDJa5xSzHHhwAYVYw5Gxb1P5xjR41wnt
x-ms-exchange-antispam-messagedata: 2WN9Oqmytuah2X/Wt0XEr8OHqltWoKMl89pA6TvTUSdWENcdRdCJcSTNCXXM7SUcTTd+9QDhkAsyyFV1RXEW1O6ap2808q90j1u/RAP6fBf2gS1HU5zjmXlopGJU1UwZMoAXqus7I8c7Ke4iPb6xUQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C77DFD421DCE724C94ECE7A6D38FC909@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0468f2db-54c4-4cd7-0246-08d7d6662591
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 17:57:30.0573 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZXYX7Ux6XulkJeJAFeIbLDSifGVn9KQwuB3Xfzup/uZEnNOR9qitqVW2S+8Cto0ce3HEaW6wgWeAMKstWrbJWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3843
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/6Hf_YOPUGwvhgpklgZsyra2_uMU>
Subject: Re: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 17:57:37 -0000
Thanks Adrian for the thorough review and great comments! On your broader-scope question, I see the difference in definition of private-use versus experimental-use, but I tend to agree with you that for this use case they are overlapping in intent or need. My view would be to keep only Experimental Use. Thanks, Carlos. > 2020/04/01 午後1:06、Adrian Farrel <adrian@olddog.co.uk>のメール: > > Hi all, > > As document shepherd I have done another review of this document to see > whether it is ready for working group last call as the authors have > asked to progress the draft. > > Sadly, I don't think this document is ready. The ideas have crystallised > fine, but the write-up here is lacking. > > I have a number of small editorials and some larger questions and issues > set out below. I also have one question that has broader scope: > > For [IANA-MT] and [IANA-Sub-6] you now have both 'Private Use' and > 'Experimental Use'. I struggle to see how this makes sense. The uses > decribed in RFC 8126 are sufficiently similar that it is unusual to > have both categories defined for a single registry. I don't see anything > in the descriptive text in this document that makes clear why you need > both categories and how an implementation would decide which range to > select a code point from. > > If we can clean up all these points, the document may be ready. > > Best, > Adrian > > == > > Abstract > > s/.././ > > -- > > Abstract > > "The updates are mostly..." > Text like this always makes me ask, "What about the rest?" > > -- > > All section heading should use capitalisation > > -- > > 1. > > d/among other things/ > > -- > > 1. > > RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC > 8029, but the registrations can be further clarified and their > definitions more precise. > > Maybe... > > RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC > 8029. This document further clarifies the entries in those > registries and makes the definitions more precise. > > -- > > 1. > > This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by > updating two groups of registries. > > Maybe... > > This document updates RFC 8029 [RFC8029] and RFC 8611 [RFC8611] by > updating two groups of registries as follows: > > -- > > 1. > > First the registries for Message Types [IANA-MT], Reply Modes > [IANA-RM] and Return Codes [IANA-RC]. The changes to these > registries are minor. > > NEW > > First, the registries for Message Types [IANA-MT], Reply Modes > [IANA-RM], and Return Codes [IANA-RC] are updated. The changes to > these registries are minor. > > -- > > 2. > > OLD > > o a small set of code points (4 code points) for experimental use is > added, actually they are take from the range for "Private Use". > > NOTE > The code points are not taken from the range for "Private Use". Rather, > the "Private Use" range is reduced. So... > > NEW > > o a small set of code points (4 code points) for Experimental Use is > added by reducing the range for "Private Use". > > -- > > 2. > > o In the listing of assignments the term "Vendor Private Use" is > changed to "Private Use" > > I'd move this to the top of the list so that the term "Private Use" has > context when it is used in other bullets. > > -- > > 3. > > I'm not sure that the text in the base section (i.e., before 3.1) adds > to the document. > > -- > > 3.1 first two bullets > > s/requires/require/ > s/the/they/ > > However, how I don't see how these bullets belong in this document. What > do the processing rules have to do with the IANA registries? The > paragraph immediately after the bullets would seem to be enough. > > But then I got to Section 4 and discovered that you are also changing > the use of terminology around mandatory/optional. This goes further > than the name of the document, the first sentence of the Abstract, and > the whole of the Introduction. So, I think you need to work out what > the document is intended to do (fix the registries, or fix the > registries *and* fix the descriptions of how parameters are used) and > then clarify the document accordingly. > > -- > > 3.1 > > Each of the blocks have code point spaces with the following > s/have/has/ > > -- > > The range of each TLV and sub-TLV registry is divided into to blocks, > one with a range from 0 to 49161 for TLVs and sub-TLVs that require a > response if not recognized. Another block in the range from 49161 to > 65535, this block is for TLVs and sub-TLVs that may be silently > dropped if not recognized. > > Are you sure that 49161 shouldn't read 32767 and 32768 in the two cases > here? > > s/into to/into two/ > > -- > > 3.1.1 > > s/Expereimetal USe/Experimental Use/ > s/Privagte/Private/ > > -- > > 3.1.1 > > Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use > are handled as any other unrecognised TLV or sub-TLV. > > o If the unrecognized TLV or sub-TLV is from the Experimental Use > range (37144-37147) or from the Private Use range (31748-32767) a > the Return Code of 2 ("One or more of the TLVs was not > understood") will be sent in the echo response. > > o If the unrecognized TLV or sub-TLV is from the Experimental Use > range (64512-64515) or from the Private Use range (64515-65535) > the TLVs SHOULD be silently ignored. > > IETF does not prescribe how recognized or unrecognized Experimental > Use and Private Use TLVs and sub-TLVs are handled in experimental or > private networks, that is up to the agency running the experiment or > the private network. The statement above relates to how standard > compliant implementations will treat the unrecognized TLVs and sub- > TLVs from these ranges. > > Firstly, just like the issue with section 3.1, I think you should just > focus on the IANA considerations. > > Secondly, this final paragraph seems to say something that may go > beyond what is in the base RFCs and is an update beyond simply a change > to the IANA section. > > But, you could boil this down to a simplified statement of: there are > two sets of ranges, one for "send error if not recognised" and one for > "silently ignore if not recognised". If you do that, then the contents > of 3.1.1 would collapse into 3.1. > > -- > > 3.2 > > OLD > This section lists the changes to each MPLS LSP Ping Registry, in > Section 6.1, Section 6.2 and Section 6.3 the changes are detailed and > it is shown what the IANA registry version of the registration > procedures and assignments would look like. > NEW > This section lists the changes to each MPLS LSP Ping Registry. > Section 6.1, Section 6.2 and Section 6.3 set out how the new > versions of the IANA registries should look, together with the > registration procedures. > > -- > > 3.2.1 > > Many of the same issues as shown for Section 2 > > -- > > 4. > > s/ths/that/ > > -- > > 4.1 > > s/is nows/is now/ > > -- > > 4.1 > > This was presumably a problem in 8029, but perhaps we can fix it here. > You propose... > > TLV and sub-TLV Types greater than or equal to 32768 (i.e., with > the high-order bit equal to 1) are TLVs and sub-TLVs that SHOULD > be ignored if the implementation does not understand or support > them. > > You should say under what conditions and how they SHOULD may be varied. > This is probably... > > , but such implementations MAY choose to send an error as it > would have done if the high-order bit had been clear. > > -- > > 4.1.1 > > s/Comments to this changes/Comments to these changes/ > > s/change in two/changed in two/ > > -- > > I stumbled over section 4.1.1. It claims to provide comments on the > changes and provides three numbered bullet points: > 1. This doesn't describe a change > 2. This describes two changes > 3. Does describe a change, but the text is not clear that it describes > a change. > > -- > > There is load of duplication in this document because you have: > - some repetition of text from existing RFCs > - duplication between sections describing how the text should look and > section 6 that instructs IANA > > I think you could have trimmed this substantially by: > - simply pointing at the relevant section of the updated RFC > - explaining what you want to change > - pointing at the relevant piece of section 6 for the new text > > Result: > - shorter draft > - less scope for errors > > -- > > The whole of section 4.2 (including 4.2.1) says "changes aligned with > the rest of this document" but doesn't actually say what the changes > are. > > -- > > 4.2.1 > > s/tu return am/to return an/ > s/ir only/only/ > > However, that whole paragraph seems to be missing meaning. > > -- > > 5. > > This document only updates IANA registries, not how the code-points > in the registries are used. This should not create any new threats. > > The first sentence seems to be false. That is, you are also updating the > terminology to clarify the rules about when a TLV or sub-TLV can be > ignored if it is not understood. > > However, this is a good thing for security because it makes it more > likely that implementations will be consistent and harder to attack. > > -- > > 6. It would be really nice if the whole of section 6 could refer to > registries using precise names (probably in quotes). You want IANA to > be easily able to find the right registries. > > -- > > 6. > > IANA is requested to update the LSP Ping name space as described in > this document and documented in the Appendixies. > > What Appendixies? > > -- > > 6.1 > > The captions for the tables are at best confusing, but probably wrong. > > -- > > 6.2 > > Consistent with the comment for section 6, this whole section is very > confusing! Are you actually asking IANA to do anything in this section? > > -- > > In section 6.3, I can't parse what you asking IANA to do. >
- [mpls] Review of draft-ietf-mpls-lsp-ping-registr… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… tom petch
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Mach Chen
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel