Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
Shivakumar Channalli <shivakumar@juniper.net> Tue, 01 June 2010 12:55 UTC
Return-Path: <shivakumar@juniper.net>
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 D9CEA3A69DE for <mpls@core3.amsl.com>; Tue, 1 Jun 2010 05:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.349
X-Spam-Level:
X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, 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 CR8TIay08D3F for <mpls@core3.amsl.com>; Tue, 1 Jun 2010 05:55:46 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 25BFD3A6818 for <mpls@ietf.org>; Tue, 1 Jun 2010 05:55:45 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTAUDRF8KUSK0lFGVet/qbgDA8HwktJK/@postini.com; Tue, 01 Jun 2010 05:55:34 PDT
Received: from emailbng1.jnpr.net (10.209.194.15) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.2.254.0; Tue, 1 Jun 2010 05:47:12 -0700
Received: from emailbng5.jnpr.net ([10.209.194.35]) by emailbng1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 18:17:09 +0530
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: Tue, 01 Jun 2010 18:17:08 +0530
Message-ID: <D4C56A454A92494AB873F2FBB8E4154807F3E232@emailbng5.jnpr.net>
In-Reply-To: <C6921F0EC3DEDB419A67B42AB1EA2138018FA834@XMB-RCD-206.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
thread-index: Acr97fovWGELdmbmzEeKyK2GG/RPxQAPfh+gAA7zTAAACB51UAADMoBgAArX9yAAAVdKwAAetk9gAJBjYkAAAOyKIA==
References: <C8246DBC.2063E%swallow@cisco.com><D4C56A454A92494AB873F2FBB8E4154807F3DBF7@emailbng5.jnpr.net><C6921F0EC3DEDB419A67B42AB1EA2138018FA2E5@XMB-RCD-206.cisco.com><05542EC42316164383B5180707A489EE1D5F5B6AA5@EMBX02-HQ.jnpr.net><C6921F0EC3DEDB419A67B42AB1EA2138018FA56D@XMB-RCD-206.cisco.com> <05542EC42316164383B5180707A489EE1D5F5B6AB4@EMBX02-HQ.jnpr.net> <96327EF53EF71A48806DE2DFC034D57F0BAEA090@xmb-sjc-22b.amer.cisco.com> <D4C56A454A92494AB873F2FBB8E4154807F3DDBA@emailbng5.jnpr.net> <C6921F0EC3DEDB419A67B42AB1EA2138018FA834@XMB-RCD-206.cisco.com>
From: Shivakumar Channalli <shivakumar@juniper.net>
To: "Shaleen Saxena (ssaxena)" <ssaxena@cisco.com>, "Santiago Alvarez (saalvare)" <saalvare@cisco.com>, Nitin Bahadur <nitinb@juniper.net>
X-OriginalArrivalTime: 01 Jun 2010 12:47:09.0044 (UTC) FILETIME=[8C40FB40:01CB0188]
Cc: mpls@ietf.org
Subject: Re: [mpls] Last Calls on P2MP LSP Ping and Enhanced DS Map
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: Tue, 01 Jun 2010 12:55:50 -0000
|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
- [mpls] Last Calls on P2MP LSP Ping and Enhanced D… George Swallow
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shivakumar Channalli
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shaleen Saxena (ssaxena)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Nitin Bahadur
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Nitin Bahadur
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shaleen Saxena (ssaxena)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Santiago Alvarez (saalvare)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Nitin Bahadur
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Santiago Alvarez (saalvare)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Nitin Bahadur
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shivakumar Channalli
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shaleen Saxena (ssaxena)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shivakumar Channalli
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shivakumar Channalli
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shaleen Saxena (ssaxena)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shivakumar Channalli
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Aissaoui, Mustapha (Mustapha)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Nitin Bahadur
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Aissaoui, Mustapha (Mustapha)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Aissaoui, Mustapha (Mustapha)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shaleen Saxena (ssaxena)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Shaleen Saxena (ssaxena)
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Nitin Bahadur
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… babu s
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Nitin Bahadur
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… Babu Subramani
- Re: [mpls] Last Calls on P2MP LSP Ping and Enhanc… babu s