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

[Ron Bonica <[e-mail]>]

Works for me.

> -----Original Message-----
> From: Stewart Bryant [mailto:[e-mail]]
> Sent: Wednesday, December 6, 2017 12:19 PM
> 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
> 
> 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=