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

[Nitin Bahadur <nitinb at juniper.net>]

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 fFrom mpls-bounces at ietf.org  Wed Nov 19 09:17:35 2008
Return-Path: <mpls-bounces at ietf.org>
X-Original-To: mpls-archive at megatron.ietf.org
Delivered-To: ietfarch-mpls-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id AA60E3A6972;
	Wed, 19 Nov 2008 09:17:35 -0800 (PST)
X-Original-To: mpls at core3.amsl.com
Delivered-To: mpls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9EF093A6972
	for <mpls at core3.amsl.com>; Wed, 19 Nov 2008 09:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 0GkoYkVG1AsH for <mpls at core3.amsl.com>;
	Wed, 19 Nov 2008 09:17:33 -0800 (PST)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161])
	by core3.amsl.com (Postfix) with ESMTP id 690E83A681D
	for <mpls at ietf.org>; Wed, 19 Nov 2008 09:17:33 -0800 (PST)
Received: from source ([66.129.228.6]) by exprod7ob104.postini.com
	([64.18.6.12]) with SMTP
	ID DSNKSSRKK5zIJo3Den2m/oNW3l3b6wMsH0Gt at postini.com;
	Wed, 19 Nov 2008 09:17:33 PST
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emsmtp02.jnpr.net
	with Microsoft SMTPSVC(6.0.3790.3959); 
	Wed, 19 Nov 2008 09:17:27 -0800
Received: from 172.23.9.192 ([172.23.9.192]) by emailcorp3.jnpr.net
	([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; 
	Wed, 19 Nov 2008 17:17:27 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Wed, 19 Nov 2008 11:17:11 -0600
From: Nitin Bahadur <nitinb at juniper.net>
To: George Swallow <swallow at cisco.com>,
	<zali at cisco.com>,
	<mpls at ietf.org>
Message-ID: <C549A637.2FA3A%nitinb at juniper.net>
Thread-Topic: draft-nitinb-lsp-ping-rsvp-protection-00
Thread-Index: AclKaqh1GkcUsnOnPE+ErZ9HZ/K5ug==
Mime-version: 1.0
X-OriginalArrivalTime: 19 Nov 2008 17:17:27.0971 (UTC)
	FILETIME=[B2929730:01C94A6A]
Subject: Re: [mpls] draft-nitinb-lsp-ping-rsvp-protection-00
X-BeenThere: mpls at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls>
List-Post: <mailto:mpls at ietf.org>
List-Help: <mailto:mpls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
	<mailto:mpls-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mpls-bounces at ietf.org
Errors-To: mpls-bounces at ietf.org

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 por 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
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls


ing.

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
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls