Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

"Shaleen Saxena (ssaxena)" <ssaxena@cisco.com> Wed, 20 October 2010 16:27 UTC

Return-Path: <ssaxena@cisco.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B053A692A for <mpls@core3.amsl.com>; Wed, 20 Oct 2010 09:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 rBeg3EGphGD6 for <mpls@core3.amsl.com>; Wed, 20 Oct 2010 09:27:53 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 048C63A67FD for <mpls@ietf.org>; Wed, 20 Oct 2010 09:27:52 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACK2vkytJV2Y/2dsb2JhbAChTXGjA5xRhUoEhFWJAA
X-IronPort-AV: E=Sophos;i="4.57,356,1283731200"; d="scan'208";a="172774205"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 20 Oct 2010 16:29:25 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o9KGTPdr029731; Wed, 20 Oct 2010 16:29:25 GMT
Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 11:29:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 20 Oct 2010 11:29:25 -0500
Message-ID: <C6921F0EC3DEDB419A67B42AB1EA213802DE8DB0@XMB-RCD-206.cisco.com>
In-Reply-To: <D4C56A454A92494AB873F2FBB8E4154808E456C9@emailbng5.jnpr.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
Thread-Index: Acr97fovWGELdmbmzEeKyK2GG/RPxQAPfh+gAA7zTAAACB51UAADMoBgAArX9yAAAVdKwAAetk9gAJBjYkAAAOyKIBtzHt5wAAtTD7AAARimwAA7YTFA
References: <D4C56A454A92494AB873F2FBB8E4154808E455EB@emailbng5.jnpr.net> <C6921F0EC3DEDB419A67B42AB1EA213802D12462@XMB-RCD-206.cisco.com> <D4C56A454A92494AB873F2FBB8E4154808E456C9@emailbng5.jnpr.net>
From: "Shaleen Saxena (ssaxena)" <ssaxena@cisco.com>
To: Shivakumar Channalli <shivakumar@juniper.net>
X-OriginalArrivalTime: 20 Oct 2010 16:29:25.0761 (UTC) FILETIME=[F5CD3F10:01CB7073]
Cc: mpls@ietf.org
Subject: Re: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
X-BeenThere: mpls@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@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2010 16:27:56 -0000

Hi,

I understand your PHP usage better now. However changing the behavior of
T bit will not prevent multiple responses from tail nodes. If you plan
to use Responder Identifier TLV to limit that, then it will work for bud
nodes as well (unless bud node itself is the target). So changing the
behavior of the T bit for PHP is only a partial solution to the problem.

Shaleen


-----Original Message-----
From: Shivakumar Channalli [mailto:shivakumar@juniper.net] 
Sent: Tuesday, October 19, 2010 8:41 AM
To: Shaleen Saxena (ssaxena)
Cc: mpls@ietf.org; Nitin Bahadur
Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt

Shaleen,

||  H - M1 - B - M2 - T
||
||Here:
|| H: Head
|| M1, M2: Two mid-point nodes
|| B: Bud
|| T: Tail

|As per your suggestion, when T flag is used in a PHP scenario:
|- Bud nodes will never respond, even if it is their turn to do so,

Let me explain it again. If a packet is sent with TTL 2
Bud node B receives 2 packets:
1) Labeled packet, due to TTL expiry (for which it would normally
perform a  swap and send it to M2)
2) unlabelled packet, which arrives due to PHP done at M1

The suggestion is to drop the unlabelled packet(2) at bud, if "TTL
expiry flag" is set, because it landed in B due to PHP done at M1, not
due to label TTL expiry.


|- Tail nodes will keep responding to all echo requests where TTL is
|greater than their depth.
|
|I am not sure how this behavior can be helpful to traceroute.

Tail nodes will always get a single copy of the packet unlike bud nodes.

More ever, if the responder-id tlv is present a node would never respond
back, unless the criterions for responder-id tlv are met correctly.


|The original problem is that bud and tail nodes keep responding to
|traceroute requests, for TTL greater than their depth. The extra
|responses can be prevented if the nodes check for label expiry. However
|without the label, traceroute packets for various TTL values look the
|same. If you have a suggestion on how to solve this problem in a PHP
|scenario, I will be willing to put it in the draft.


This problem can be solved by dropping +unlabelled packets+ at +bud
node+, if TTL expiry flag is set in the request. 




$hiv...



|-----Original Message-----
|From: Shaleen Saxena (ssaxena) [mailto:ssaxena@cisco.com]
|Sent: Tuesday, October 19, 2010 5:08 PM
|To: Shivakumar Channalli
|Cc: mpls@ietf.org; Nitin Bahadur; Shaleen Saxena (ssaxena)
|Subject: RE: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Hi Shivakumar:
|
|I did not put the suggested text after discussions with other authors.
|The behavior you suggest does not solve the problem of receiving
|multiple responses from various bud and tail nodes during traceroute.
|
|As per your suggestion, when T flag is used in a PHP scenario:
|- Bud nodes will never respond, even if it is their turn to do so,
|- Tail nodes will keep responding to all echo requests where TTL is
|greater than their depth.
|
|I am not sure how this behavior can be helpful to traceroute.
|
|The original problem is that bud and tail nodes keep responding to
|traceroute requests, for TTL greater than their depth. The extra
|responses can be prevented if the nodes check for label expiry. However
|without the label, traceroute packets for various TTL values look the
|same. If you have a suggestion on how to solve this problem in a PHP
|scenario, I will be willing to put it in the draft.
|
|Regards,
|Shaleen
|
|-----Original Message-----
|From: Shivakumar Channalli [mailto:shivakumar@juniper.net]
|Sent: Tuesday, October 19, 2010 2:00 AM
|To: Shaleen Saxena (ssaxena)
|Cc: mpls@ietf.org; Nitin Bahadur
|Subject: [mpls] I-D Action:draft-ietf-mpls-p2mp-lsp-ping-12.txt
|
|Shaleen,
|Please find the mail thread, where in we had a discussed about PHP
|scenario.
|
|
|
|$hiv...
|
|
|
|-----Original Message-----
|From: Shivakumar Channalli
|Sent: Tuesday, June 01, 2010 6:17 PM
|To: 'Shaleen Saxena (ssaxena)'; Santiago Alvarez (saalvare); Nitin
|Bahadur
|Cc: mpls@ietf.org
|Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
|
||I will updated the P2MP OAM draft to reflect the PHP scenario.
||
||So does PHP always happen before bud node? Consider the following
||topology:
||
||  H - M1 - B - M2 - T
||
||Here:
|| H: Head
|| M1, M2: Two mid-point nodes
|| B: Bud
|| T: Tail
|
|PHP will happen before tail (T i.e pure egress) also.
|In the example T is pure egress, so packet should be processed by T,
but
|in case of B (bud node) it should be dropped.
|
|That's why it should be clearly specified as
|
|"In p2mp LSP case, if a node (other than ++pure egress++) receives a
|+MPLS
|LSP trace packet+, without any label, then it should drop the packet
|without processing"
|
|In other words, "if a bud node receives a unlabelled packets , then it
|should be dropped"
|
|
||
||So will both M1 and M2 send out unlabelled packets? Will the TTL of
the
||packet cause any different behavior from M1 and M2?
|
|I guess, there should not be any problems as such.
|
|
|
||Also, your suggestion applies to only packets with T bit turned on,
||correct? If it is for all ping/trace packets, then I foresee some
||issues, where certain nodes will never respond.
|
|That's correct. The packets should be dropped only if T bit is set.
|Other wise in ping mode of operation, we may not get reply at all if we
|apply this rule to all packets.
|
|
|
|...$hiv
|
|
|
||-----Original Message-----
||From: Shaleen Saxena (ssaxena) [mailto:ssaxena@cisco.com]
||Sent: Tuesday, June 01, 2010 5:51 PM
||To: Shivakumar Channalli; Santiago Alvarez (saalvare); Nitin Bahadur
||Cc: mpls@ietf.org; Shaleen Saxena (ssaxena)
||Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
||
||Hi Shiv, Nitin,
||
||I will updated the P2MP OAM draft to reflect the PHP scenario.
||
||So does PHP always happen before bud node? Consider the following
||topology:
||
||  H - M1 - B - M2 - T
||
||Here:
|| H: Head
|| M1, M2: Two mid-point nodes
|| B: Bud
|| T: Tail
||
||So will both M1 and M2 send out unlabelled packets? Will the TTL of
the
||packet cause any different behavior from M1 and M2?
||
||Also, your suggestion applies to only packets with T bit turned on,
||correct? If it is for all ping/trace packets, then I foresee some
||issues, where certain nodes will never respond.
||
||Thanks,
||Shaleen
||
||
||> -----Original Message-----
||> From: Shivakumar Channalli [mailto:shivakumar@juniper.net]
||> Sent: Saturday, May 29, 2010 11:13 AM
||> To: Santiago Alvarez (saalvare); Nitin Bahadur; Shaleen Saxena
||> (ssaxena)
||> Cc: mpls@ietf.org
||> Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
||>
||>
||> |> 1. precluding bud node support
||> Another way is to try to solve bud node issue in case of PHP
||>
||> |> 2. bud node receiving duplicate traffic (label and unlabeled)
||> |> Cheers.
||> Receiving unlabelled packet in case of PHP can be solved by
following
||a
||> simple rule.
||>
||> "In p2mp LSP case, if a node (other than pure egress) receives a
|+MPLS
||> LSP trace packet+, without any label, then we should drop the packet
||> without processing"
||>
||> Reason: In trace route mode we want packets to reach control plane
|due
||> to TTL expiry, but in PHP p2mp mode packets are also received by bud
||> nodes due the PHP. As a result we can make an assumption that, the
||> packet received by control plane is not due to TTL expiry, and drop
||the
||> packets.
||>
||>
||> ...$hiv
||>
||>
||>
||> |-----Original Message-----
||> |From: Santiago Alvarez (saalvare) [mailto:saalvare@cisco.com]
||> |Sent: Saturday, May 29, 2010 6:03 AM
||> |To: Nitin Bahadur; Shaleen Saxena (ssaxena); Shivakumar Channalli
||> |Cc: mpls@ietf.org; Santiago Alvarez (saalvare)
||> |Subject: RE: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
||> |
||> |It seems to me that, in order to find PHP acceptable for P2MP LSPs,
||> one
||> |the these two need to be acceptable:
||> |1. precluding bud node support
||> |2. bud node receiving duplicate traffic (label and unlabeled)
||> |Cheers.
||> |
||> |SA
||> |--
||> |> -----Original Message-----
||> |> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
||Behalf
||> |Of
||> |> Nitin Bahadur
||> |> Sent: Friday, May 28, 2010 4:52 PM
||> |> To: Shaleen Saxena (ssaxena); Shivakumar Channalli
||> |> Cc: mpls@ietf.org
||> |> Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS
|Map
||> |>
||> |>
||> |> Shaleen,
||> |>
||> |> > I was referring to
||> |> > http://tools.ietf.org/html/draft-ietf-mpls-rsvp-te-no-php-oob-
||> |> > mapping-04
||> |>
||> |> This draft does not say that PHP *must not* be used ever for RSVP
||> |P2MP.
||> |> This draft specifies a requirement for non-PHP behavior and
solves
||> |that
||> |> problem.
||> |>
||> |> > . Do you have an application where you use PHP? Is P2MP TE
||> |> > with PHP going to be deployed in service provider networks?
||> |>
||> |> Yes...we have customers (in deployment) using P2MP with PHP.
||> |>
||> |> nitin
||> |> _______________________________________________
||> |> mpls mailing list
||> |> mpls@ietf.org
||> |> https://www.ietf.org/mailman/listinfo/mpls