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.