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

[Stewart Bryant <[e-mail]>]

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://www.ietf.org/mailman/listinfo/gen-art