Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 30 June 2015 11:35 UTC

Return-Path: <adrian@olddog.co.uk>
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 BABE11A8991 for <mpls@ietfa.amsl.com>; Tue, 30 Jun 2015 04:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vZ6EX5ZYPmFm for <mpls@ietfa.amsl.com>; Tue, 30 Jun 2015 04:35:48 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14311A8989 for <mpls@ietf.org>; Tue, 30 Jun 2015 04:35:47 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t5UBZfFu004241; Tue, 30 Jun 2015 12:35:41 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t5UBZeUS004232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2015 12:35:40 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'George Swallow (swallow)'" <swallow@cisco.com>, lizho.jin@gmail.com, 'loa' <loa@pi.nu>, 'mpls' <mpls@ietf.org>, 'mpls-chairs' <mpls-chairs@tools.ietf.org>, 'draft-ietf-mpls-lsp-ping-relay-reply' <draft-ietf-mpls-lsp-ping-relay-reply@tools.ietf.org>, 'db3546' <db3546@att.com>
References: <0cc101d0a92b$58745050$095cf0f0$@olddog.co.uk> <D1AEF47A.3B610%swallow@cisco.com>
In-Reply-To: <D1AEF47A.3B610%swallow@cisco.com>
Date: Tue, 30 Jun 2015 12:35:42 +0100
Message-ID: <024201d0b328$e60e6070$b22b2150$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEYMGV4hvNaRq5cW16qQoAALBpeNZ8176Sg
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21644.007
X-TM-AS-Result: No--17.282-10.0-31-10
X-imss-scan-details: No--17.282-10.0-31-10
X-TMASE-MatchedRID: hls5oAVArl+nykMun0J1wl2036HHwFm/C/ExpXrHizzjsTquy0JRizUi 2rTIOxGGbxfxhPoewY1ggI58ZUEmGRAMjqIFshtGmlaAItiONP0Q2zDF7O7/jv0YXg59YwMhlDg V9tdYJkluNSyu9YTqcopMj7hWkuSqp7oFtZkbM7RaAZ0EWklHOpE+3DCX3uibZDbgHp/C6pR86l H54QlVeOCsrTjP4N9Ql8UzeScHmiN7EVbt+QyLTLdQIb8hCnY+9mnDjfUPq5406dhcpwNHEPcFW 8xdeHLra6ik7aSNiPhpqTJxwvN1VOVHGbcDbAq6OX/V8P8ail3Yr6U3ZlQkdsRB0bsfrpPI6T/L TDsmJmg=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/TtlA6R-r7SfpGTDUfdt3A2BtVmc>
Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: <https://mailarchive.ietf.org/arch/browse/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, 30 Jun 2015 11:35:54 -0000

Thanks George,

[snip]

> >>> I tried to work out how things would pan out if two ASes on the path
> >>> used the same address space within their AS. Would an address appear in
> >>> the stack and seem to be routable when it is really an address in the
> >>> other AS?
> >> [Lizhong] we have an example in section 5. And address of P1 and P2
> >> could be same. In that case, ASBR1 must add its interface address
> >> facing ASBR2 with the K bit set. Then relay reply will not be miss-routed.
> >
> >Ah, I get it.
> >But this relies on ASBT1 setting the K bit.
> >So I suspect this needs to not be a special case: you need to require
> >that the domain boundary always sets the K bit.
> 
> GS>  I made such a change awhile back.  It got shot down on the list.
> There was push back due to the requirement for topological awareness
> within the LSP Ping module.
> 
> Adrian - If you want to try pushing back on that, would you send a message
> to the list on just this topic and see if we can convince folks.

Consider this to be the push-back! :-)

It seems that the domain boundary (probably just an ASBR?) either has to know
that some other domain in the path is using the same address space as it is
using, or it has to know that it is an ASBR. Without applying the K bit for one
of these criteria, the mechanism is broken.

I suggest that the former is hard to know, but the latter is easy and can be
injected into the "LSP Ping module". This is NOT topological awareness since it
does not do harm to have extra K bits set, so in the relatively rare case of an
ASBR being on the path of an LSP that does not actually exit the AS, no harm
will be done.

The authors may want to ask the chairs how they establish whether there is WG
agreement on this point.

Cheers,
Adrian