Subject: Re: [mpls] draft-nitinb-lsp-ping-rsvp-protection-00

From: Nitin Bahadur <[email-masked]>
Date: Wed, 19 Nov 2008 11:17:11 -0600

Folks,

In the mpls wg meeting, there was a proposal to use proxy lsp-ping to solve
the bypass lsp-ping problem. I read through the proxy-ping draft and I have
some comments and concerns.

> 1. Introduction
> In particular, the
> procedures defined in this document only allow testing of a FEC stack
> consisting of a single FEC.

There could be multiple FECs if we have LDP over RSVP (at the ingress) and
there is a bypass for the RSVP LSP.

> Further the discussion is cauched in terms of multipoint LSPs.
Cauched? Typo?
We need it for both P2P and P2MP.

> 2. Proxy Ping Overview
> The message is then encapsulated in a UDP packet.
We would need to change this for in-band proxy-ping.
UDP packet does not make sense because it requires that ingress knows the IP
address of each transit and there is IP routing between ingress and
transits.

> The proxy LSR then determines if it is authorized to send the
> specified MPLS echo request on behalf of the initiator.
Overhead in terms of policies/configuration is too high. Given that the
request is initiated by the LSP ingress, we need a way to avoid this.

> 3.2.1. Sending an MPLS proxy ping reply
> The source IP address is a routable address of the proxy LSR; the source
> port is the well-known UDP port for LSP ping.

We don't need this for bypass lsp-ping. The reply needs to come back to the
ingress. It's a waste of processing if the reply comes to the proxy/transit
and the transit then forwards it to the ingress.

Moreover, in MPLS-TP, there might be no *IP routable path* from proxy to
ingress and from egress to proxy. There might be even no LSP from proxy to
ingress and from egress to proxy. Only solution possible is to have the
egress send the message back to the ingress directly.

Given that the echo request is initiated at the ingress, it will be
unnecessary overhead to:
1) First create a proxy ping request on the ingress (instead of a regular
ping request)
2) On the proxy/transit to covert the proxy-ping request parameters into a
regular ping parameters and then forward it.

IMO, the overhead of proxy ping state machine is not needed at all for this
application.
 
Proxy-ping solves a problem, but I'm not sure if it is the right procedure
for solving the bypass lsp-ping problem.

I might have missed something due to my lack of detailed understanding of
proxy lsp-ping. I would be interested in hearing how one could use
proxy-ping (without complex manipulations) to solve the bypass lsp-ping
problem.

Thanks
Nitin

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls