IETF Logo Mail Archive

[mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt

"Nobo Akiya (nobo)" <nobo@cisco.com> Wed, 14 August 2013 22:10 UTC

Return-Path: <nobo@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EF421F94FD for <mpls@ietfa.amsl.com>; Wed, 14 Aug 2013 15:10:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFxwxI47G0x7 for <mpls@ietfa.amsl.com>; Wed, 14 Aug 2013 15:10:17 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B12E221F95A6 for <mpls@ietf.org>; Wed, 14 Aug 2013 15:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2268; q=dns/txt; s=iport; t=1376518216; x=1377727816; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=9XsxYvlv3WRN4OSAEjJ3rEnDsIbyTBeuNxJRGyCiSRU=; b=E0bGvP4v9sNmTIP4OdIAou89MIuYIwy/lb4tUDBHa69hYdrQP5SFe+m7 UdbkkTgyLfYZN6TI8cgkyR+rEn2hOeiCYUiGdgGKVvuE4uXmfFn323hDd CoDaCchExvoAWFJ3a5j09i6sYHhqsH5DogvoqwIrZS+97FWmRAbhF8l/S o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao0GABj/C1KtJXG8/2dsb2JhbABbgmUhgQW/I4EgFm0HgiYBAQM6PxIBKhRCJgEEDg2ICAG5IpAfMYMidwOpNoMbgio
X-IronPort-AV: E=Sophos;i="4.89,880,1367971200"; d="scan'208";a="247463356"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 14 Aug 2013 22:10:16 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7EMAGZh003715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 22:10:16 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 17:10:15 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: "draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org" <draft-ietf-mpls-return-path-specified-lsp-ping@tools.ietf.org>
Thread-Topic: Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt
Thread-Index: Ac6ZIv/azjWY8ahbTN6wXwSKa+Cm7g==
Date: Wed, 14 Aug 2013 22:09:53 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941B77BC3D@xmb-aln-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.213.104]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] Comments on draft-ietf-mpls-return-path-specified-lsp-ping-12.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 14 Aug 2013 22:10:23 -0000

Dear Authors, et al,

Draft adds new reply mode (5 - Reply via Specified Path) which looks to provide initiator great control on return path. Draft considers bidirectional LSP, and allows specifying of reverse LSP in a new TLV, but ... for bidirectional LSP ping, having reply mode to indicate reverse LSP would appear to take care of large majority of use, and there'll be no need to encode/decode additional TLV. Is there any reason why reply mode to specify reverse LSP is not added?

And reply path TLV allows for initiator to specify a particular return path, but allows responder to choose different path if initiator specified one cannot be accommodated. This aspect is very interesting. Reason being that specifying of the "right" reply mode in echo request seems to be getting more and more complicated these days.

For example, bidirectional LSP with some transit nodes non-co-routed:
    - ping:
        * IP reply mode works
        * Reverse LSP reply mode works
    - ping with TTL terminating on mid:
        * IP reply mode works
        * Reverse LSP reply mode may or may not work
    - traceroute:
        * IP reply mode works
        * Reverse LSP reply mode may or may not work

In above cases, what I would like to specify in most cases is to say "take reverse LSP as return path if available, otherwise take IP return path". Yes reply path TLV allows this, but I'm thinking if this can be done in a simpler way.

Reply mode 2: Reply via an IPv4/IPv6 UDP packet
Reply mode 4: Reply via application level control channel
Reply mode 6: Reply via reverse LSP (assume this exists)

Let's say there existed:

Reply mode 7: Reply via pre-defined preference

When responder receives reply mode 7, then return path is chosen from pre-defined preference list (ex: control-channel > reverse LSP > IP). Reply mode used can be encoded in the reply mode field of echo rely so initiator knows which was used.

I see the new TLV useful for specific scenarios, but I've been trying to see how things (implementations and operations) can be simplified for those non-specific (majority) of cases. Was something like above considered as part of this draft?

Regards,
Nobo

v2.23.0 | Report a Bug | By Email