Re: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document

"Nobo Akiya (nobo)" <nobo@cisco.com> Fri, 18 July 2014 13:03 UTC

Return-Path: <nobo@cisco.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 BE2BE1A0AEB for <mpls@ietfa.amsl.com>; Fri, 18 Jul 2014 06:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.502
X-Spam-Level:
X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 wMqiUjBaqglS for <mpls@ietfa.amsl.com>; Fri, 18 Jul 2014 06:03:19 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C7E1A0AD9 for <mpls@ietf.org>; Fri, 18 Jul 2014 06:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2197; q=dns/txt; s=iport; t=1405688599; x=1406898199; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nBlnEqXqClEELD0wwI3u8Sh0xuov3t0VnY3fP2aMP6s=; b=ZVtjIK2zeeOWuZJFfjsEEGKKXkSgXLiiYwojG0nou9MIn83PGrr9AFG+ MRjkStm42FKoTpjKhZ4pPuupcbFG6dcgyLNPbHNVKERJ7/8XDItpS1yZW M+qooT1EITm160ZuojeIVB2VP42HgXQeCElRc1oeiSkdt86GW4n2bsMLg I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAF0ayVOtJV2a/2dsb2JhbABZgmokgS3LEoEhAYEIFnaEBAEBBDo/EAIBCCIUBQsyJQIEAQ0NiDoBxDAXjxoxB4MugRgFjkOhEYICgUKCMQ
X-IronPort-AV: E=Sophos;i="5.01,685,1400025600"; d="scan'208";a="340835179"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jul 2014 13:03:18 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6ID3IQ9006793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 13:03:18 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 08:03:18 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: "Stewart Bryant (stbryant)" <stbryant@cisco.com>, Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, Adrian Farrel <adrian@olddog.co.uk>
Thread-Topic: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document
Thread-Index: AQHPmeuyvEqL5d1/1ESW4A59wRYjn5ukwbEwgAFIiYD//87NQA==
Date: Fri, 18 Jul 2014 13:03:17 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E26C63B@xmb-aln-x01.cisco.com>
References: <53BAA7BA.2060903@pi.nu> <CECE764681BE964CBE1DFF78F3CDD3941E26BAEC@xmb-aln-x01.cisco.com> <53C8FA57.6080802@cisco.com>
In-Reply-To: <53C8FA57.6080802@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.212.73]
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/jxLmS2iRTPzTu0-ysyO2i-3FT-4
Cc: "draft-bryant-mpls-oam-udp-return@tools.ietf.org" <draft-bryant-mpls-oam-udp-return@tools.ietf.org>
Subject: Re: [mpls] Poll to see if we have support to make draft-bryant-mpls-oam-udp-return an mpls working group document
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, 18 Jul 2014 13:03:37 -0000

Hi Stewart,

Clipping out ones with closure.
Please see below.

[...]
> > [snip from Section 4]
> >     If the URO is expected but is not present in Query message and an
> >     MPLS-PLDM Response is requested out-of-band, the Query message
> MUST
> >     NOT be processed further.  If received over a bidirectional LSP, the
> >     control code of the Response message MUST be set to "Error - Missing
> >     TLV" and a Response SHOULD be sent over the reverse LSP.
> >
> > [snip from Section 4.3]
> >     If an Out-of-band response is requested and the Address object or the
> >     URO is missing, the Query SHOULD be dropped in the case of a
> >     unidirectional LSP.  If both these TLVs are missing on a
> >     bidirectional LSP, the control code of Response message should set to
> >     "Invalid Message" and the response SHOULD be sent over the reverse
> >     LSP.
[...]
> > In the second snippet from Section 4.3 above, I believe the condition
> should be && and not ||.
> I don't think so.
> 
> Address only was the original mode and although I have doubts about
> whether there are deployments we need to support it until it is deprecated.
> Thus you might find an address TLV indicating a response over IP is required
> or a URO indicating a response over UDP/IP is required.
> 
> I think we agreed that we needed to support multiple UROs in certain
> circumstances however I am wondering whether we need to support both
> modes (IP and URO) or the same packet.
[...]

I see. I got the impression from the document that having both is not disallowed, thus it's an error if neither are included in the Query (i.e. &&). But you are right, there's no point in keeping around (IP) since (URO) is a superset. Technically I do not see any issue if this document deprecated (IP). Responder implementations will likely need to support both for a while, thus perhaps having a text around the transition period (i.e. what happens when both (IP) and (URO) are in the Query) somewhere in the document (ex: Appendix?) may be beneficial.

Either way, texts in both snippets should be updated.

Thanks!

-Nobo