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=