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

"" <> Wed, 01 July 2015 15:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A24E1A90BE for <>; Wed, 1 Jul 2015 08:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6fEzDoBdmD9S for <>; Wed, 1 Jul 2015 08:39:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DDE11A90CC for <>; Wed, 1 Jul 2015 08:39:31 -0700 (PDT)
Received: by paceq1 with SMTP id eq1so24818065pac.3 for <>; Wed, 01 Jul 2015 08:39:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=date:from:to:subject:references:mime-version:message-id :content-type; bh=g5URMVpecRcb4jXQWIjO2mp7V95rilPlNRowrxAo2Sg=; b=RXWbATI6WwyXq2f7sjF13w1CddpItDRM6N+AO+/xbAR2nDf1v6gY3GPZOxppIU5pP5 AzRqKt9ES2VdYtOiDz98aLyWiW0PLMnD3ihnxIDw7+IgzlCmNJJ4ViXjiRMv2ZG6TSvP DZx30u9VOaP+MAcm/3gXFZdY+eLMk7PMfOg84nDYLLpzGrJrutwhXneKLIlhv7+VP7CW LC/hDGFTrwY3oNmBNClT6tJXQCGmNySSOjwHY6ZSid+WuZHK4ou+Ril5St7VsSRNMwO+ 62I40O9LYMhRr9bM8glRHFoiKGf7gUCUTmwl2VbpLkDuZzGk4eUrEEsWDsLlmb1lx2vR vf5w==
X-Received: by with SMTP id h8mr17478886pde.66.1435765170774; Wed, 01 Jul 2015 08:39:30 -0700 (PDT)
Received: from Lizhong ([]) by with ESMTPSA id pc9sm2697555pdb.6.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 08:39:29 -0700 (PDT)
Date: Wed, 1 Jul 2015 23:40:14 +0800
From: "" <>
To: adrian <>, swallow <>, loa <>, mpls <>, mpls-chairs <>, draft-ietf-mpls-lsp-ping-relay-reply <>, db3546 <>
References: <0cc101d0a92b$58745050$095cf0f0$>, <>, <024201d0b328$e60e6070$b22b2150$>
X-Priority: 3
X-GUID: E45855EC-4BDF-400E-8626-E2CA0BD47A8D
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 140[en]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart705474475165_=----"
Archived-At: <>
Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jul 2015 15:39:33 -0000

Then in the document section 4.2, we could say:
One example of spanning two address domains is the ASBR node. Other cases are also possible, and out of the scope of this document. 

From: Adrian Farrel
Date: 2015-06-30 19:35
To: 'George Swallow \(swallow\)';; 'loa'; 'mpls'; 'mpls-chairs'; 'draft-ietf-mpls-lsp-ping-relay-reply'; 'db3546'
Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
Thanks George,
> >>> 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.