Re: [mpls] draft-bonica-mpls-self-ping: Response to comments from the mike

[Loa Andersson <[e-mail]>]

Folks,

I did a chair-review that I sent to the authors. In that review (the
rest is pretty much editorial) I clearly miss the the "non-relationship" 
with 4379.

I think what I see from the discussion between Sam and Ron are
that we want to:

- borrow the message format from 4379
- create a new message typ
- I with Sam that that message type should be named to avoid being
   confused with MPLS Echo Request and MPLS Echo Reply
- whether we'd like to register this message type in the "Message
   Type" registry in "Multi-  Protocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" is an open question.
- but since the new message type will come out of the "Standards
   Action" registry the document needs to be Standards Track.

/Loa

On 2014-11-26 07:56, Sam Aldrin wrote:
> Hi Ron,
>
> Thanks for the reply.
>
> [sorry for the top post]
>
> Glad that we are on the same page.
> Now that we are clear that this ID is not related to RFC4379 but borrows
> the model and format of packet structure, etc, I do not have a problem
> as such, provided the draft text is worded that way.
> Not just for the reasoning purposes, but adds clarity to what you intend
> to do and not confuse readers with LSP ping.
> W.r.t. Request / Reply, I prefer to have new terms defined and identify
> them in the terminology section. For ex: 'Self Ping Message' or
> something else.
>
> RFC4379 may not define different message formats for Echo Request and
> Echo Reply, it clearly identifies those message types.
>
> cheers
> -sam
>
>
> On Tue, Nov 25, 2014 at 3:28 PM, Ronald Bonica <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Sam and Carlos,____
>
>     __ __
>
>     You are correct in that LSP Self-ping has very little to do with LSP
>     Ping [RFC 4379]. In fact, aside from borrowing the message format,
>     it has **nothing** to do with RFC 4379]! ____
>
>     __ __
>
>     Rationale follows:____
>
>     __ __
>
>     __-__LSP Self-ping messages do not carry the router alert message____
>
>     __-__Transit and egress LSRs don’t examine or process LSP Ping
>     messages; they simply forward them____
>
>     __-__Only the ingress LSR listens for LSP Self Ping messages____
>
>     __-__The ingress LSR listens for LSP Self Ping messages on a
>     different port than it listens for LSP Ping messages____
>
>     __-__The ingess LSR never responds to an LSP Self Ping message.____
>
>     __ __
>
>     I will make this explicit in the next version of the draft.____
>
>     __ __
>
>     Sam,____
>
>     __ __
>
>     You raise another point that Loa also raised in his chairs review.
>     RFC 4379 does not specify Echo Request and Echo Reply messages. It
>     specifies a single Echo message with a Message Type field (request
>     or reply). In draft-bonica-mpls-self-ping, I retain that
>     terminology. However, Loa suggests that I refer to an Echo Reply
>     message for clarity. I tend to agree with Loa. What do you think?____
>
>     __ __
>
>                                                                                                                                                       Ron____
>
>     ____
>
>     __ __
>
>     *From:*Sam Aldrin [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Tuesday, November 25, 2014 3:49 AM
>     *To:* Ronald Bonica
>     *Cc:* Shah, Himanshu; Nobo Akiya (nobo); Shahram Davari; Thomas
>     Nadeau; [e-mail] <mailto:[e-mail]>
>
>
>     *Subject:* Re: [mpls] draft-bonica-mpls-self-ping: Response to
>     comments from the mike____
>
>     __ __
>
>     Ron,____
>
>     __ __
>
>     I do not think the reason specifying it as LSP ping is correct. ____
>
>     Although you are using LSP ping Echo reply like packet format, it is
>     not LSP ping packet as it doesn't confirm to RFC4379.____
>
>     For ex: MPLS Echo Reply is only sent when MPLS Echo Request is
>     received. Neither does it detect any dataplane failures, which is
>     the title of the RFC. ____
>
>     __ __
>
>     Hence, I am not convinced that this ID warrants informational RFC,
>     which is based on RFC4379.____
>
>     __ __
>
>     But if you want to keep the ID out side the perview of RFC4379, then
>     it should be updated accordingly and discussion should be on those
>     lines.____
>
>     __ __
>
>     cheers____
>
>     -sam____
>
>         On Nov 21, 2014, at 2:19 PM, Ronald Bonica <[e-mail]
>         <mailto:[e-mail]>> wrote:____
>
>         __ __
>
>         Shah,____
>
>         ____
>
>         Because there are no interoperability implications, there is no
>         need for a standards track RFC. However, because LSP Ping sends
>         traffic off-box, an INFORMATIONAL RFC is appropriate. LSP Ping
>         traffic might be detected by counters, intrusion detection
>         devices and firewalls. We should document all of the OAM traffic
>         that we generate.____
>
>         ____
>
>                                             Ron____
>
>         ____
>
>         ____
>
>         *From:*Shah, Himanshu [mailto:[e-mail]]
>         *Sent:*Thursday, November 20, 2014 7:05 PM
>         *To:*Nobo Akiya (nobo); Sam Aldrin; Shahram Davari
>         *Cc:*Thomas Nadeau; Ronald Bonica; [e-mail]
>         <mailto:[e-mail]>
>         *Subject:*RE: [mpls] draft-bonica-mpls-self-ping: Response to
>         comments from the mike____
>
>         ____
>
>         /Understand documenting helpful techniques (more useful during
>         restoration/re-optimization cases) as informational RFC, but I
>         believe IETF usually/____
>
>         /entertains proposals which has interoperability implications,
>         AFAIK./____
>
>         //____
>
>         /Which is what others are saying as well…/____
>
>         //____
>
>         /Thanks,/____
>
>         /himanshu/____
>
>         //____
>
>         *From:*Nobo Akiya (nobo) [mailto:[e-mail]]
>         *Sent:*Thursday, November 20, 2014 6:23 PM
>         *To:*Sam Aldrin; Shahram Davari
>         *Cc:*Shah, Himanshu; Thomas Nadeau; Ronald Bonica;[e-mail]
>         <mailto:[e-mail]>
>         *Subject:*RE: [mpls] draft-bonica-mpls-self-ping: Response to
>         comments from the mike____
>
>         ____
>
>         Thanks for not shooting me Sam but I’m really not the messengerJ____
>
>         ____
>
>         If there is a good proposal that covers set of LSP types with
>         [virtually] no imitations, then documenting such proposal has an
>         value, IMHO.____
>
>         ____
>
>         I’d agree that current contents of this document may not provide
>         sufficient value to be pursued as an informational document, but
>         I’m not hopeless that something could come out of this.____
>
>         ____
>
>         Thanks!____
>
>         ____
>
>         -Nobo____
>
>         ____
>
>         *From:*Sam Aldrin [mailto:[e-mail]]
>         *Sent:*Thursday, November 20, 2014 2:57 PM
>         *To:*Shahram Davari
>         *Cc:*Nobo Akiya (nobo); Shah, Himanshu; Thomas Nadeau; Ronald
>         Bonica;[e-mail] <mailto:[e-mail]>
>         *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response to
>         comments from the mike____
>
>         ____
>
>         Hi Nobo,____
>
>         ____
>
>         [without shooting the messenger]____
>
>         ____
>
>         In addition to what you listed, would like to see details on how
>           this ID will improve the performance at Egress should be
>         clarified.____
>
>         i.e. IP routing Vs OAM process (w/o FEC validation). Also, how
>         this model helps if reverse IP path is not available
>         (inter-domain, reverse path broken, non-routable ingress IP
>         address) and to what gain?____
>
>         ____
>
>         There are many ways the LSP ping is being used, both as
>         proprietary and also part of eco system.____
>
>         If we go by the logic that this ID is needed, we will have slew
>         of new ID’s detailing different usage models.____
>
>         ____
>
>         Hence, I totally agree with what Shahram and others have
>         indicated.____
>
>         ____
>
>         -sam____
>
>         ____
>
>             On Nov 20, 2014, at 11:15 AM, Shahram Davari
>             <[e-mail] <mailto:[e-mail]>> wrote:____
>
>             ____
>
>             Hi,____
>
>
>             Since the procedures in this draft generates and processes
>             the test packets on the same router and since other routers
>             just forward normally,  why do we even need a draft? There
>             is no interoperability requirements, and each vendor can
>             implement what they like.____
>
>             ____
>
>             Thanks____
>
>             Shahram____
>
>             ____
>
>             *From:*mpls [mailto:[e-mail]]*On Behalf Of*Nobo
>             Akiya (nobo)
>             *Sent:*Thursday, November 20, 2014 10:57 AM
>             *To:*Shah, Himanshu; Thomas D. Nadeau; Sam Aldrin
>             *Cc:*Ronald Bonica;[e-mail] <mailto:[e-mail]>
>             *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response
>             to comments from the mike____
>
>             ____
>
>             Hi,____
>
>             ____
>
>             Sort of summarizing what’s been stated but here’s my
>             observation of draft-bonica-mpls-self-ping.____
>
>             ____
>
>             1.LSP Ping and BFD MPLS already do what is being proposed.____
>
>             2.Ron needs a mechanism that is more efficient on egress
>             LSRs, with respect to resources and operational aspects.____
>
>             3.Any probe packet having destination IP address as the
>             ingress LSR has limitations in terms of how effective it can
>             verify the DP readiness.____
>
>             4.The proposal by Ron is limited to those LSPs that signal
>             via ordered mode (ex: LDP independent mode will not work) -
>             same problem as (3).____
>
>             ____
>
>             If the intent of draft-bonica-mpls-self-ping is just to
>             document what has been implemented or what is being
>             implemented, I’d like to request followings to be captured
>             in the document.____
>
>             -limitations (3 and 4) so that readers are aware of them.____
>
>             -usage of non-127/8 address as destination IP address in
>             MPLS echo request/reply deviates from RFC4379.____
>
>             ____
>
>             If the intent of draft-bonica-mpls-self-ping is to advocate
>             a mechanism for efficient MPLS DP readiness test, and I’d
>             like to request that:____
>
>             -requirements (2) are well captured.____
>
>             -S-BFD be evaluated (as it addresses the efficiency
>             requirements and does not have limitations described by 3
>             and 4).____
>
>             ____
>
>             Himanshu, I have one comment in-line below. Please look for
>             [NOBO].____
>
>             ____
>
>             ____
>
>             *From:*mpls [mailto:[e-mail]]*On Behalf
>             Of*Shah, Himanshu
>             *Sent:*Thursday, November 20, 2014 10:36 AM
>             *To:*Thomas D. Nadeau; Sam Aldrin
>             *Cc:*Ronald Bonica;[e-mail] <mailto:[e-mail]>
>             *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response
>             to comments from the mike____
>
>             ____
>
>             /This is exactly what I said at Mic./____
>
>             /We have been deploying MPLS for a while and if such DP
>             active verification was necessary, vendors have solved it
>             without/____
>
>             /standard specific solution, may that be BFD or self-ping./____
>
>             //____
>
>             /One of the argument made was that client BFD session
>             detects that “tunnel is active but DP is not”./____
>
>             /Does it imply there is some kind of UNI signaling going on
>             between PE and CE to indicate that tunnel has become/____
>
>             /active, commence data? And the idea is that PE will refrain
>             notification until self-ping verify DP active?/____
>
>             //____
>
>             /If that is not the case then this technique is not even
>             useful – self ping is not actually causing the DP to become
>             active,/____
>
>             /If it doesn’t become active in the time window, what is PE
>             going to do?/____
>
>             //____
>
>             [NOBO] That is another interesting aspect of the whole
>             solution. However, I believe that the problem scope of this
>             document is much smaller: ingress LSR to detect readiness of
>             RSVP signaled LSP. For RSVP signaled LSP, only the LSP that
>             is “passing the test” can be tied to the tunnel as the
>             active LSP, so at least the ingress LSR will not pump
>             traffic into the tunnel without knowing whether DP
>             end-to-end is ready or not. Assuming that there are other
>             ways to get to the egress LSR from this ingress LSR, then
>             the problem is solved. Otherwise the ingress LSR will drop
>             the traffic but the problem is contained to that network
>             node (i.e. packets are not traversing un-ready LSP).____
>
>             ____
>
>             Thanks!____
>
>             ____
>
>             -Nobo____
>
>             ____
>
>             ____
>
>             //himanshu/____
>
>             //____
>
>             *From:*mpls [mailto:[e-mail]]*On Behalf
>             Of*Thomas D. Nadeau
>             *Sent:*Thursday, November 20, 2014 9:43 AM
>             *To:*Sam Aldrin
>             *Cc:*Ronald Bonica;[e-mail] <mailto:[e-mail]>
>             *Subject:*Re: [mpls] draft-bonica-mpls-self-ping: Response
>             to comments from the mike____
>
>             ____
>
>             ____
>
>             To me what is described in the draft seems like this is a
>             description of a device/vendor feature that automates the
>             basic procedures of 4379/etc.. This can and has been done
>             for quite some time using other means such as onboard
>             automated scripts/actions after paths are
>             established/signaled. I say this not to be glib, but because
>             I built such a thing about 10 years ago that has been
>             deployed widely.  Also, as Sam says, there is some deviation
>             from RFC4379 which we should ask is worth the additional
>             complication (and required implementation + associated
>             delay/etc...) versus just using the existing means. ____
>
>             ____
>
>             The bottom line is that we should be asking ourselves
>             whether or not this something we really need to standardize.____
>
>             ____
>
>             —Tom____
>
>             ____
>
>             ____
>
>             ____
>
>                 On Nov 19, 2014:10:28 PM, at 10:28 PM, Sam Aldrin
>                 <[e-mail] <mailto:[e-mail]>>
>                 wrote:____
>
>                 ____
>
>                 Hi Ron,____
>
>                 ____
>
>                 Still trying to understand the need for the draft,
>                 hence, have few of questions and need clarifications.
>                 Appreciate your response in advance.____
>
>                 ____
>
>                 1. (clarification q) The Ingress LSR sends the Echo
>                 request, with destination IP address to self, and
>                 forwards to Egress LSR (sec 2), correct?  Is this the
>                 only thing which identifies the Ingress LSR or something
>                 else too?____
>
>                 2. What happens if there is LSP breakage or something
>                 and the Echo request ends up on transit LSR? Doesn't it
>                 process? I see that draft says, this will avoid control
>                 plane processing. How so? The packet is forwarded from
>                 ingress to egress, which means, the egress will have to
>                 process the packet i.e. look up the ip address to send
>                 it back to ingress.____
>
>                 ____
>
>                 Draft says "The egress LSR forwards the MPLS Echo
>                 message to its destination, the____
>
>                     ingress LSR.  The egress LSR forwards the MPLS Echo message exactly____
>
>                     as it would forward any other packet."____
>
>                   ____
>
>                 Could you explain, how egress forwards the packet back to ingress w/o looking up the packet IP header i.e. in the data plane and no additional control plane of OAM process?____
>
>                 3. Is the assertion that, if Echo Reply is received back
>                 at the ingress then it is failure, rather it should
>                 receive Echo Request back at Ingress, correct?____
>
>                 4. Why can't you use LSP proxy ping to self via Egress?____
>
>                 ____
>
>                 Will followup with additional questions, if any, based
>                 on your responses.____
>
>                 ____
>
>                 cheers____
>
>                 -sam____
>
>                 ____
>
>                     On Nov 19, 2014, at 8:38 AM, Ronald Bonica
>                     <[e-mail] <mailto:[e-mail]>>
>                     wrote:____
>
>                     ____
>
>                     Folks
>
>                     At IETF 91, the following points were raised with
>                     regard to draft-bonica-mpls-self-ping:
>
>                     1) Why not use BFD?
>                     2) Self-ping does not diagnose FIB programming
>                     errors in which an LSR other than the egress
>                     de-encapsulates and forwards the packet.
>                     3) How does Self ping verify a bidirectional LSP's
>                     readiness to carry traffic in both directions?
>                     4) Why does MPLS Self ping use MPLS Echo packets, as
>                     opposed to ICMP echo packets or some other packet
>                     format?
>
>                     Responses follow:
>
>                     1) Why not use BFD?
>
>                     Self Ping is an extremely light-weight protocol. A
>                     typical Self Ping session emits one or two packets
>                     and terminates less than one second after
>                     initiation. Self-ping requires no configuration or
>                     control plane resources on the egress LSR.
>
>                     By contrast, BFD is designed to verify
>                     bi-directional connectivity over a longer period of
>                     time. Therefore, MPLS Self Ping is appropriate in
>                     environments where BFD is too resource intensive.
>
>                     2) Self-ping does not diagnose programming errors in
>                     which an LSR other than the egress de-encapsulates
>                     and forwards the packet.
>
>                     Self Ping is designed to verify LSP readiness
>                     without consuming control plane resources on the
>                     egress router. It is not designed to diagnose
>                     programming errors in which an LSR other than the
>                     egress de-encapsulates and forwards the packet.
>                     Mechanisms that diagnose such issues are available
>                     [RFC 4950]. However, they are more resource intensive.
>
>                     3) How does Self ping verify a bidirectional LSP's
>                     readiness to carry traffic in both directions?
>
>                     In order to verify bidirectional LSP readiness, RSVP
>                     instantiates two LSP Self Ping sessions, one at each
>                     end of the LSP. The LSR at one end of the LSP
>                     initiates a self ping session when it receives a
>                     RESV message. The LSR at the other end of the LSP
>                     initiates a Self Ping Session when it sends a RESV
>                     message. Each LSP endpoint forwards traffic over the
>                     LSP only after the LSP Self Ping session terminates
>                     successfully
>
>                     4) Why does LSP Self Ping use MPLS Echo packets, as
>                     opposed to some other packet format?
>
>                     LSP Self Ping could have used many packet formats.
>                     The only hard requirement was to have one 64-bit
>                     field in which the 64 bit session identifier could
>                     be encoded. The MPLS Echo packet was convenient
>                     because its Senders Handle is 64-bits long.
>
>                     I will update the draft to reflect this information.
>
>                     Ron Bonica
>
>                     _______________________________________________
>                     mpls mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/mpls____
>
>                 ____
>
>                 _______________________________________________
>                 mpls mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/mpls____
>
>     __ __
>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


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