Re: [mpls] MPLS-RT review of draft-bonica-mpls-self-ping

[Loa Andersson <[e-mail]>]

Ron,

I would support a new message, I was never that found of sending
unsolicited Echo Reply message even if I saw no real reason not to.

You'll need a new message type, will you allocate that from the
LSP Ping registry, or create a registry of your own? And I'd like to
see the message format captured.

I also wonder if this brings the discussion about Informational/
Standards Track? DOn't you pass the border into creating a new
protocol if you do?

/Loa

On 2015-03-13 09:56, Ronald Bonica wrote:
> Carlos,
>
> You have a good point. Reusing the LSP Ping message format wasn’t the
> best idea in the world because it forces us to consider interactions
> with LSP Ping.
>
> Could we solve the problem by defining a new message that is very
> similar to the LSP Ping message? The new message will contain only the
> following fields from the LSP Ping message:
>
> -Sender’s handle
>
> -Sequence Number
>
> -Timestamp sent (seconds)
>
> -Timestamp sent (microseconds)
>
> All remaining fields from the LSP Ping message will be omitted.
>
>
>                                                                                         Ron
>
> *From:*Carlos Pignataro (cpignata) [mailto:[e-mail]]
> *Sent:* Thursday, March 12, 2015 1:54 PM
> *To:* Adrian Farrel
> *Cc:* Ronald Bonica; Gregory Mirsky; <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [mpls] MPLS-RT review of draft-bonica-mpls-self-ping
>
> Adrian,
>
> One additional nuance is that this document sends and unsolicited “Echo
> Reply” (i.e., not in response to an Echo Request), when RFC 4379 (PS) says:
>
> https://tools.ietf.org/html/rfc4379#section-4.5
>
> 4.5.  Sending an MPLS Echo Reply
>
>     An MPLS echo reply is a UDP packet.  It MUST ONLY be sent in response
>
>     to an MPLS echo request.  The source IP address is a routable address
>
>     of the replier; the source port is the well-known UDP port for LSP
>
>     ping.  The destination IP address and UDP port are copied from the
>
>     source IP address and UDP port of the echo request.
>
> ...
>
> Can an Informational doc change behavior of a PS?
>
> Thanks,
>
> Carlos.
>
>     On Mar 12, 2015, at 8:00 AM, Adrian Farrel <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>     Looks informational to me. And looks like 2119 language is appropriate.
>
>     Thanks,
>
>     Adrian
>
>     *From:*Ronald Bonica [mailto:[e-mail]]
>     *Sent:*12 March 2015 01:24
>     *To:*Gregory Mirsky;[e-mail]
>     <mailto:[e-mail]>;[e-mail]
>     <mailto:[e-mail]>
>     *Cc:*[e-mail]
>     <mailto:[e-mail]>;[e-mail] <mailto:[e-mail]>
>     *Subject:*RE: MPLS-RT review of draft-bonica-mpls-self-ping
>
>     Greg,
>
>     In the message below, you question whether
>     draft-bonica-mpls-self-ping should be INFORMATIONAL or PS. In a
>     similar vein, you ask whether RFC 2119 language should be used.
>
>     When I wrote the draft, I considered both, couldn’t decide, and
>     tossed a coin ;-)
>
>     AFAIKS, the IETFs criteria for PS are a bit fuzzy. You might argue
>     that the draft should be PS because it defines “bits on the wire”.
>     But on the other hand, you might argue that it doesn’t need to be PS
>     because:
>
>     -It doesn’t address interoperability requirements (because the
>     sender and receiver are the same node)
>
>     -It doesn’t request any IANA assignments
>
>     I would be very happy to let somebody else decide whether the draft
>     should be INFORMATIONAL or PS. Maybe the chairs or ADs can offer an
>     opinion?
>
>
>                                                        Ron
>
>     *From:*Gregory Mirsky [mailto:[e-mail]]
>     *Sent:*Monday, March 09, 2015 5:02 PM
>     *To:*[e-mail]
>     <mailto:[e-mail]>;[e-mail]
>     <mailto:[e-mail]>
>     *Cc:*[e-mail]
>     <mailto:[e-mail]>;[e-mail] <mailto:[e-mail]>
>     *Subject:*RE: MPLS-RT review of draft-bonica-mpls-self-ping
>
>     Dear All,
>
>     I've been assigned to review draft-bonica-mpls-self-ping.
>
>     The document is very well written, the problem in focus is clearly
>     stated, and the proposed solution well described.
>
>     I do have a number of concerns with the status of the document and
>     the approach as presented:
>
>     ·document intended track is Informational even though the solution
>     being positioned as "new, light-weight protocol". If this is indeed
>     new protocol or even extension of the existing one, then I expect
>     there must be requests to IANA allocations. At this time "This
>     document makes no request of IANA." Either LSP Self-ping can be
>     characterized through re-use of already existing protocols and
>     approaches, or document should be switched to Standards track;
>
>     _______________________________________________
>     mpls mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mpls
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]