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

[Ronald Bonica <[e-mail]>]

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