Stewart, Having thought about it for a while, you may be right. PROBE was meant to be an IP tool. Pseudo-wire endpoints were an afterthought, and not a very good afterthought at that. Let's remove the E-bit (aka P-bit) and limit Probe to querying the status of IP interfaces. Ron > -----Original Message----- > From: Stewart Bryant [mailto:stewart.bryant@xxxxxxxxx] > Sent: Wednesday, December 6, 2017 6:24 AM > To: Ron Bonica <rbonica@xxxxxxxxxxx>; Joel M. Halpern > <jmh@xxxxxxxxxxxxxxx>; gen-art@xxxxxxxx > Cc: draft-ietf-intarea-probe.all@xxxxxxxx; int-area@xxxxxxxx; ietf@xxxxxxxx; > pals-chairs@xxxxxxxxxxxxxx; mpls-chairs@xxxxxxxx; l2tpext-chairs@xxxxxxxx; The > IESG <iesg@xxxxxxxx> > Subject: Re: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07 > > 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@xxxxxxxxxxxxxxx] > >> Sent: Monday, December 4, 2017 4:19 PM > >> To: Ron Bonica <rbonica@xxxxxxxxxxx>; gen-art@xxxxxxxx > >> Cc: draft-ietf-intarea-probe.all@xxxxxxxx; int-area@xxxxxxxx; > >> ietf@xxxxxxxx > >> 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@xxxxxxxxxxxxxxx] > >>>> Sent: Thursday, November 30, 2017 4:45 PM > >>>> To: gen-art@xxxxxxxx > >>>> Cc: draft-ietf-intarea-probe.all@xxxxxxxx; int-area@xxxxxxxx; > >>>> ietf@xxxxxxxx > >>>> 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@xxxxxxxx > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mail > > man_listinfo_gen-2Dart&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDT > > XcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > AWF2EfpHcAwrDThKP8&m=3aYviNNhuXQukU > > cgg_np7tq6-CJZDv9M_hHVW_ulyzo&s=7TxRC3k3Vsozba6OX8GmaFv_c- > 9INm2pcVkjqx > > sPpr0&e=