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

[Ron Bonica <[e-mail]>]

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.
> >
> >