Re: [mpls] MPLS-RT review of draft-bryant-mpls-oam-udp-return

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> Fri, 20 June 2014 22:37 UTC

Return-Path: <mustapha.aissaoui@alcatel-lucent.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827731A041F for <mpls@ietfa.amsl.com>; Fri, 20 Jun 2014 15:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNkuFTpyZmHr for <mpls@ietfa.amsl.com>; Fri, 20 Jun 2014 15:37:15 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A06F1A00E8 for <mpls@ietf.org>; Fri, 20 Jun 2014 15:37:15 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s5KMbC9h025310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jun 2014 17:37:13 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s5KMbC3l002463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jun 2014 18:37:12 -0400
Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.109]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Fri, 20 Jun 2014 18:37:12 -0400
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: MPLS-RT review of draft-bryant-mpls-oam-udp-return
Thread-Index: AQHPf+mIXbTUoLuth0OZOvkep32erZtg29GwgBk2SSCAAJ3y8A==
Date: Fri, 20 Jun 2014 22:37:12 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340D946AB974@US70UWXCHMBA01.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/2HuCXjlG2jWSDsqLH7d7nJ2GBf4
Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" <draft-bryant-mpls-oam-udp-return@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] MPLS-RT review of draft-bryant-mpls-oam-udp-return
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 20 Jun 2014 22:37:19 -0000

Dear all,
I was asked to review this draft. I understand the need to provide a more granular out-of-band reply using a querier provided UDP port. Thus it is a useful draft to pursue.

However, there are a couple of issues I found in this draft which if addressed would make in my view the document ready for WG status:

1. the first issue has to do with what I interpreted (correct me if I am wrong) as a change to the reply procedures in RFC 6374. This draft states in Section 4:
"
If either the Return Address Object or Return UDP Port Object is not
   present in Query message and an MPLS-PLDM Response is requested out-
   of-band, the Query message MUST NOT be processed further.  
"
This modifies the behavior of RFC 6374 which does allow the reply to be sent over the address in the Source Address Object or over some configured out-of-band response mechanism if none of the Source and Return Address objects were included in the MPLS-PLDM query message. 

2. The second issue has to do with the fact that the UDP Port Object is a separate object from the address to be used with. I do not think this is a good idea since the responder node can easily combine an address provided in the Source Address Object with this UDP port and send it to the wrong node in a cluster system.
I propose that a new Return Address object be created which combines both the return address and return UDP port.

Regards,
Mustapha.