Re: [Int-area] [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07
Stewart Bryant <stewart.bryant@gmail.com> Wed, 06 December 2017 11:24 UTC
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304F9124BAC; Wed, 6 Dec 2017 03:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 wYeIr7aJyn2c; Wed, 6 Dec 2017 03:24:10 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 2EEEC124205; Wed, 6 Dec 2017 03:24:10 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id g75so6661495wme.0; Wed, 06 Dec 2017 03:24:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=pOqAWRdGA+COCD0b7SBN1/GHgMcorzpe5SKM/eL6XjY=; b=WUvye78DUwkVqvHJK17pvg6Sd+ZGkLzSQ+HKVwKXzQcIavkV8qiDLWTK/GUssLlmhL jQK31aXIeYmDBlxo2CmPlTcJL0izOdCkB6XwVMMFDip8JhXC9QPIVmdVhb0qUiRR605E 1wXoUQRdai4tGPZE28PvM1Aa8QHm5f54t1ZUyJSPzwj+W+mefG4umZJssNIE0cn7Ka7Y yBHBlXR2oXD5d0w2wsA+CsJcMEkkyi15gXuzpF8l/guOiXJXrTEQsVg51TCJ+KcXdtLr FpoG5Jkd1iJWn+EdTv0lYTj9kJohywVcc3CE0u4GCf+yHsxe9NbModKfSGmwxksL51Xt ilCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pOqAWRdGA+COCD0b7SBN1/GHgMcorzpe5SKM/eL6XjY=; b=KvphGPxxq8jDklNh03EXYnQJAVdnbgDs+jy0z9MdUD28VhefU7Gyq3poFrIyfQ3OC1 qNXSyU27++IqBARcTRqQEXCNURLEV3cm4fDSF/Xtptmjt/Mml9Xq0PVmnjyHBIYUiqtQ lMjgGO7uc9cLvv7mQRK8pGRcGu/o6ywLI78piEW4Uor6cJ6qwPLkf6TT2Af5kGmfMkNc 7GL6rpxSrK954jHTWV1eaGha2aQnLV8TO6YPtL9qoSbkN76+m4yI1ccg3nOudH+3WAMv d/wiMnTqYsnMohQ/aQVqWkEBtoJlHyBMLGJa4/ViUEjIFRMqIJ4LJTRiwhlhnOcUlCoA +Ebg==
X-Gm-Message-State: AKGB3mIVJEC52GovkxSeEXeLEZKoVpoFyvPoh1wRIxkWTXQvy3M+lAMN wfY/gZ+1SVWaupqhxDG4qU69d7NG
X-Google-Smtp-Source: AGs4zMZHxzN0g93UzrSeyJXAX0b8i1D6BXO/1kk8uPExvcQZkNMl7Xmf9gIX1RbClLm+cY0ClZeuiA==
X-Received: by 10.28.178.135 with SMTP id b129mr7742583wmf.103.1512559448207; Wed, 06 Dec 2017 03:24:08 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id l31sm3433441wrc.50.2017.12.06.03.24.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 03:24:07 -0800 (PST)
To: Ron Bonica <rbonica@juniper.net>, "Joel M. Halpern" <jmh@joelhalpern.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "draft-ietf-intarea-probe.all@ietf.org" <draft-ietf-intarea-probe.all@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "pals-chairs@tools.ietf.org" <pals-chairs@tools.ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, l2tpext-chairs@ietf.org, The IESG <iesg@ietf.org>
References: <151207827781.25922.11037452280009787600@ietfa.amsl.com> <BLUPR0501MB205123A6FAFFAC15461D1845AE3C0@BLUPR0501MB2051.namprd05.prod.outlook.com> <5fabd8f9-9663-4c7f-370b-6095f999b7b2@joelhalpern.com> <BLUPR0501MB2051CA127D79FF9ED62C2D2FAE3C0@BLUPR0501MB2051.namprd05.prod.outlook.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <f677822c-bce9-bbb7-db32-49c0c023648e@gmail.com>
Date: Wed, 06 Dec 2017 11:24:06 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <BLUPR0501MB2051CA127D79FF9ED62C2D2FAE3C0@BLUPR0501MB2051.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/U866C4j28AGYgpCu0xkbsmW3v_E>
X-Mailman-Approved-At: Wed, 06 Dec 2017 06:41:17 -0800
Subject: Re: [Int-area] [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Dec 2017 11:24:13 -0000
I cannot quite work out from the document how this works, but if we are going to PING non-IP interfaces I think the groups that work on those need some time to reflect on the implications. There are certainly a number of non-IP interfaces that may have Ethernet addresses. However, I am not sure from a quick look at the text how you would address any interface running a PW other than Ethernet. Bottom line, I think this needs to either preclude non-IP interfaces, or the groups that work with non-IP interfaces need to think through the implications, and possibly propose new identifier types. - Stewart On 04/12/2017 22:48, Ron Bonica wrote: > Joel, > > The important piece of information is that this is a pseudowire endpoint. These days, most pseudowire endpoints seem to be Ethernet. But some aren't. There are still some legacy layer 2 pseudowires hanging around. > > So, since we can't enumerate every type of pseudowire endpoint, we might as well just call it a pseudowire endpoint and provide no further information about the type. > > Ron > > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, December 4, 2017 4:19 PM >> To: Ron Bonica <rbonica@juniper.net>; gen-art@ietf.org >> Cc: draft-ietf-intarea-probe.all@ietf.org; int-area@ietf.org; ietf@ietf.org >> Subject: Re: Genart telechat review of draft-ietf-intarea-probe-07 >> >> Thank you Ron. >> >> On the E-bit (or P-Bit), is the important goal that it is a virtual interface, that it >> is pseudowire, or ? It might help there text indicating what a receiver might >> do differently based on this bit being set or unset. >> Having said that, Ethernet Pseudowire is at least a clearer distinction than just >> "Ethernet". And as long as the bit has a clear definition, any disagreement >> about what "should" be identified is clealry NOT a show stopper. >> >> Yours, >> Joel >> >> On 12/4/17 4:13 PM, Ron Bonica wrote: >>> Hi Joel, >>> >>> Thanks for the review. Responses inline...... >>> >>> Ron >>> >>> >>>> -----Original Message----- >>>> From: Joel Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Thursday, November 30, 2017 4:45 PM >>>> To: gen-art@ietf.org >>>> Cc: draft-ietf-intarea-probe.all@ietf.org; int-area@ietf.org; >>>> ietf@ietf.org >>>> Subject: Genart telechat review of draft-ietf-intarea-probe-07 >>>> >>>> Reviewer: Joel Halpern >>>> Review result: Almost Ready >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed by >>>> the IESG for the IETF Chair. Please wait for direction from your >>>> document shepherd or AD before posting a new version of the draft. >>>> >>>> For more information, please see the FAQ at >>>> >>>> <https://urldefense.proofpoint.com/v2/url?u=https- >>>> >> 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwICaQ&c=HAkYuh63rsuhr >>>> 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- >>>> >> AWF2EfpHcAwrDThKP8&m=hKAAxSQXBFWxkxtwUUKzdYcvZ22_3zrp0OZhHK >>>> V2AH4&s=X_Kje37D5HB_DdICxGgn_TkAqoXymCuJdJetUjwYPy4&e=>. >>>> >>>> Document: draft-ietf-intarea-probe-07 >>>> Reviewer: Joel Halpern >>>> Review Date: 2017-11-30 >>>> IETF LC End Date: 2017-12-13 >>>> IESG Telechat date: 2017-12-14 >>>> >>>> Summary: This document is almost ready for publication as a Proposed >>>> Standard RFC. >>>> >>>> Major issues: >>>> I can not determine from the text why two identification objects are >>>> sometimes allowed, or how they are to be used. The texts seems >>>> to indicate >>>> that they can be somehow combined to identify a single probed >> interface. >>>> But I can not see how. >>> [RB ] >>> Good catch. >>> >>> At one time I thought that this was necessary because IPv6 link-local >> addresses are not necessarily unique to the node. So, you might need to >> probe by IP address and something else (e.g., ifName). However, ifName is >> unique to the node. So, one instance of the interface identification object is >> enough. >>> I will remove that sentence. >>> >>> >>>> Minor issues: >>>> In section 2.1 in describing the usage when the probed interface is >>>> identified by name or ifindex, the text refers to MIBII, RFC 2863. I >> would >>>> expect to see it refer instead (or at least preferentially) to RFC 7223, >>>> the YANG model for the Interface stack. >>> [RB ] >>> Fair enough. I will make that change in the next version. >>> >>>> The E bit in the Extended ICMP Echo reply seems a bit odd. Shall we try >> to >>>> encode all the possible interface types in this field? Shall we try to >>>> distinguish Ethernet directly over fiber from Ethernet over ...? What >>>> about an emulated Ethernet interface (pseudowire, etc.) I do not >>>> understand why this is here, and fear it is ambiguous. >>> [RB ] >>> Looking back, I described that badly. This bit is set if the interface is a >> pseudowire endpoint and it is running Ethernet. >>> Maybe I should call it the P-bit for Pseudowire endpoint. We don't need to >> specify what type of pseudowire it is. >>> What do you think? >>> >>>> Nits/editorial comments: >>>> I find the description of the node containing the proxy interface as >> being >>>> "the probed node" as being somewhat odd, as it is not the node >> containing >>>> the probed interface. I would have expected it to be called "the proxy >>>> node"? >>> [RB ] >>> >>> Fair enough. I can make that change in the next revision. >>> >>>> Very nitpicky: In section 4, the step reading "If the Code Field is equal >>>> to No Error (0) and the L-bit is clear, set the A-Bit." probably ought to >>>> say "otherwise, clear the A-bit." >>>> >>> [RB ] >>> Fair enough. I can make that change in the next revision. >>> >>> > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
- [Int-area] Genart telechat review of draft-ietf-i… Joel Halpern
- Re: [Int-area] Genart telechat review of draft-ie… Joel M. Halpern
- Re: [Int-area] Genart telechat review of draft-ie… Ron Bonica
- Re: [Int-area] Genart telechat review of draft-ie… Ron Bonica
- Re: [Int-area] Genart telechat review of draft-ie… Joel M. Halpern
- Re: [Int-area] Genart telechat review of draft-ie… Joel Halpern
- Re: [Int-area] [Gen-art] Genart telechat review o… Stewart Bryant
- Re: [Int-area] [Gen-art] Genart telechat review o… Ron Bonica
- Re: [Int-area] [Gen-art] Genart telechat review o… Joel M. Halpern
- Re: [Int-area] [Gen-art] Genart telechat review o… Stewart Bryant
- Re: [Int-area] [Gen-art] Genart telechat review o… Ron Bonica
- Re: [Int-area] Genart telechat review of draft-ie… Alissa Cooper