Re: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07

[Stewart Bryant <[e-mail]>]

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:[e-mail]]
>> Sent: Wednesday, December 6, 2017 6:24 AM
>> To: Ron Bonica <[e-mail]>; Joel M. Halpern
>> <[e-mail]>; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]; The
>> IESG <[e-mail]>
>> 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:[e-mail]]
>>>> Sent: Monday, December 4, 2017 4:19 PM
>>>> To: Ron Bonica <[e-mail]>; [e-mail]
>>>> Cc: [e-mail]; [e-mail];
>>>> [e-mail]
>>>> 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:[e-mail]]
>>>>>> Sent: Thursday, November 30, 2017 4:45 PM
>>>>>> To: [e-mail]
>>>>>> Cc: [e-mail]; [e-mail];
>>>>>> [e-mail]
>>>>>> 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
>>> [e-mail]
>>> 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=