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

Stewart Bryant Wed, 06 Dec 2017 03:24:33 -0800

I cannot quite work out from the document how this works, but if we aregoing to PING non-IP interfaces I think the groups that work on thoseneed some time to reflect on the implications.

There are certainly a number of non-IP interfaces that may have Ethernetaddresses.

However, I am not sure from a quick look at the text how you wouldaddress any interface running a PW other than Ethernet.

Bottom line, I think this needs to either preclude non-IP interfaces, orthe groups that work with non-IP interfaces need to think through theimplications, 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:j...@joelhalpern.com]
Sent: Monday, December 4, 2017 4:19 PM
To: Ron Bonica <rbon...@juniper.net>; gen-art@ietf.org
Cc: draft-ietf-intarea-probe....@ietf.org; int-a...@ietf.org; i...@ietf.org
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:j...@joelhalpern.com]
Sent: Thursday, November 30, 2017 4:45 PM
To: gen-art@ietf.org
Cc: draft-ietf-intarea-probe....@ietf.org; int-a...@ietf.org;
i...@ietf.org
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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

Reply via email to