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

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Dec 2017 16:19:12 -0500

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:[email-masked]]
>> Sent: Thursday, November 30, 2017 4:45 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> 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.
> 
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 4 Dec 2017 21:13:58 +0000

Hi Joel,

                                   Ron

[RB ] 
Good catch.

[RB ] 

[RB ] 

What do you think?

[RB ] 

[RB ]

---

From: Ron Bonica <[email-masked]>
Date: Mon, 4 Dec 2017 22:48:31 +0000

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

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, December 4, 2017 4:19 PM
> To: Ron Bonica <[email-masked]>; [email-masked]
> 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
> 
> >> 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.
> >>
> >>      sometimes allowed, or how they are to be used.  The texts seems
> >> to indicate
> > 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.
> >
> > Looking back, I described that badly. This bit is set if the interface is a
> pseudowire endpoint and it is running Ethernet.
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Dec 2017 17:54:58 -0500

Good enough.
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 6 Dec 2017 11:24:06 +0000

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:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Ron Bonica <[email-masked]>
Date: Wed, 6 Dec 2017 16:13:45 +0000

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

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Wednesday, December 6, 2017 6:24 AM
> To: Ron Bonica <[email-masked]>; Joel M. Halpern
> <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; The
> IESG <[email-masked]>
> Subject: Re: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07
> 
> going to PING non-IP interfaces I think the groups that work on those need
> some time to reflect on the implications.
> 
> 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
> > 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
> >
> >
> >> 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
> >>
> >>>> Summary: This document is almost ready for publication as a
> >>>> Proposed Standard RFC.
> >>>>
> >>>> Major issues:
> >>>>       sometimes allowed, or how they are to be used.  The texts
> >>>> seems to indicate
> >> 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.
> >>>>       identified by name or ifindex, the text refers to MIBII, RFC
> >>>> 2863.  I
> >> would
> >>>>       The E bit in the Extended ICMP Echo reply seems a bit odd.
> >>>> Shall we try
> >> to
> >>> 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
> > 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=

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Dec 2017 11:16:40 -0500

That would be fa reasoanble way to address my genart review question.
Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 6 Dec 2017 17:18:52 +0000

Ron,

Yes you can always add it in later as an update after thinking through 
the problem in more detail.

- Stewart

---

From: Ron Bonica <[email-masked]>
Date: Wed, 6 Dec 2017 18:10:05 +0000

Works for me.

> Sent: Wednesday, December 6, 2017 12:19 PM
> Yes you can always add it in later as an update after thinking through the
> problem in more detail.
> 
> - 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.
> >
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked]; [email-masked]; [email-masked];
> >> [email-masked]; The IESG <[email-masked]>
> >> 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.
> >>
> >> 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
> >>
> >>
> >> might as well just call it a pseudowire endpoint and provide no
> >> further information about the type.
> >>>
> >>> Ron
> >>>
> >>>
> >>>> 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
> >>>>
> >>>>>> I am the assigned Gen-ART reviewer for this draft. The General
> >>>>>> Area Review Team (Gen-ART) reviews all IETF documents being
> >>>>>> processed
> >> by
> >>>>>>        that they can be somehow combined to identify a single
> >>>>>> probed
> >>>> interface.
> >>>>>>        But I can not see how.
> >>>>> [RB ]
> >>>>> Good catch.
> >>>>>
> >>>> 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.
> >>>>>>        identified by name or ifindex, the text refers to MIBII,
> >>>>>> RFC 2863.  I
> >>>> would
> >>>>>>        the probed interface.  I would have expected it to be
> >>>>>> called "the
> >> proxy
> >>>>>>        node"?
> >>>>> [RB ]
> >>>>>
> >>>>>>        Very nitpicky: In section 4, the step reading "If the Code
> >>>>>> Field is
> >> equal
> >>> man_listinfo_gen-
> 2Dart&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >> ndb3voDT

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 12 Dec 2017 14:54:23 -0500

Joel, thanks for your review. Ron, thanks for engaging with Joel. I have entered a No Objection ballot. I gather the change will be reflected in the next rev.

Alissa

> On Nov 30, 2017, at 4:44 PM, Joel Halpern <[email-masked]> wrote:
> 
> Reviewer: Joel Halpern
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Summary: This document is almost ready for publication as a Proposed Standard
> RFC.
> 
> Major issues:
>    sometimes allowed, or how they are to be used.  The texts seems to indicate
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area