Works for me. > -----Original Message----- > From: Stewart Bryant [mailto:stewart.bryant@xxxxxxxxx] > Sent: Wednesday, December 6, 2017 12:19 PM > 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 > > Ron, > > Yes you can always add it in later as an update after thinking through the > problem in more detail. > > - Stewart > > > > On 06/12/2017 16:13, Ron Bonica wrote: > > 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=