Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Nobo Akiya <nobo.akiya.dev@gmail.com> Sat, 18 April 2015 17:46 UTC

Return-Path: <nobo.akiya.dev@gmail.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 367181A870F for <mpls@ietfa.amsl.com>; Sat, 18 Apr 2015 10:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFHCKO503YJB for <mpls@ietfa.amsl.com>; Sat, 18 Apr 2015 10:46:00 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B581A8702 for <mpls@ietf.org>; Sat, 18 Apr 2015 10:45:59 -0700 (PDT)
Received: by lbbzk7 with SMTP id zk7so104032729lbb.0 for <mpls@ietf.org>; Sat, 18 Apr 2015 10:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/UQRD8GGu73HSTe/HxO/jAIIWst/xlkbi4MQYBNAEc8=; b=BMUyos7HdxkE1D5nDp36A5QvKXD56fBPwcbsbMeZxU3m3tUCy8+pXsg0g5CmYbRSF9 BAsAZaeVxgNB6mJKkK4jGepzsu9gb79i78mdVDJdkvdfKxv8AeGhE5BpIN83G8pPUixg NglQ9nmkqrFlZJ8CKzDmUDq40xEU4ZflrcscVYWOdszwvWpND253jyBV91Y0+uGzSPzt PW9JUFXz0gBjM0ROFNTuXUMNM6chfj/SDUcyPoA7CF5yEYzC5uDaAtMc6LVNtVrLMjeX TNJqH7QLHB3XbzCv92p7dXS+5btWABjXPBoAo6t4BzE7Zy+Fzkmobbc2cT6iRobDpWiU 73zA==
MIME-Version: 1.0
X-Received: by 10.152.36.73 with SMTP id o9mr9056677laj.48.1429379158218; Sat, 18 Apr 2015 10:45:58 -0700 (PDT)
Received: by 10.112.154.168 with HTTP; Sat, 18 Apr 2015 10:45:58 -0700 (PDT)
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B94CDFF@eusaamb103.ericsson.se>
References: <BY1PR0501MB143041FD755CA2819623985EA5180@BY1PR0501MB1430.namprd05.prod.outlook.com> <BY1PR0501MB14307B7B5965125211314F1FA5FE0@BY1PR0501MB1430.namprd05.prod.outlook.com> <005801d07006$789a7ed0$69cf7c70$@gmail.com> <7347100B5761DC41A166AC17F22DF1121B94CDFF@eusaamb103.ericsson.se>
Date: Sat, 18 Apr 2015 10:45:58 -0700
Message-ID: <CAFqGwGtuZOCRoXbqJmbWtYDHi3BnSfwTEr4+qk_7OZgRqTxGNw@mail.gmail.com>
From: Nobo Akiya <nobo.akiya.dev@gmail.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Content-Type: multipart/alternative; boundary=089e0160adf8f99db80514034483
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/qqhsNj-kC-Cm4gzz6Z3quvvxRwI>
Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org" <draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org>
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf
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: Sat, 18 Apr 2015 17:46:02 -0000

Hi Greg,

Snipping out ones concluded (thanks for addressing them!).


> 4. Section 2.2.4
>
> There needs to be some synchronicity between AuthType/AuthKeyID to
> specified in "this" MPLS echo request message and AuthType/AuthKeyID being
> used by BFD control packets. For example:
>
> - If BFD control packets using "new" auth is received by the egress LSR
> before MPLS echo request with new "auth" is received, all BFD control
> packets using "new" auth will be dropped.
> - To take that a step further, if BFD control packets using "new" auth is
> received by the egress LSR before "this" MPLS echo request is received by
> the egress LSR and corresponding BFD session is updated to point to the
> "new" auth , all BFD control packets using "new" auth will be dropped.
> - If BFD control packets using "new" auth is only sent X time after
> sending the MPLS echo request with new "auth", then it is not guaranteed
> that the egress LSR will still be accepting BFD control packets with "old"
> auth for X amount of time.
> - And of course there's the error case of the egress LSR not being able to
> support the specified the "new" auth specified in received MPLS echo
> request, but the ingress LSR starts using the "new" auth before it receives
> back NOSUP from the egress LSR via MPLS echo reply.
>
> I suspect if sufficient details are not defined, we would likely run into
> some inter-op issues with this aspect.
>
> GIM>> I agree, more details should be provided. How about a new paragraph
> added to the section:
>    If BFD Authentication sub-TLV used for a BFD session in Up state then
>    the Sender of the MPLS LSP Echo Request SHOULD ensure that old and
>    new modes of authentication, i.e. combination of Auth.Type and Auth.
>    Key ID, used to send and receive BFD control packets until the
>    Sender can confirm that its peer had switched to the new
>    authentication.
>
>
IMO, I think there are couple of critical aspects which have to be
described.

1. Sender:
  a. Sender of BFD authentication change via MPLS echo request must not
start using the new authentication type/key until it receives back the
acknowledgement via MPLS echo reply.
  b. BFD authentication must change to the new authentication type/key
within a reasonable time after receiving back acknowledgement via MPLS echo
reply.

2. Receiver:
  a. Receiver of BFD authentication change in MPLS echo request must setup
the BFD receive path to accept both old & new authentication type/key for
the session before sending back the acknowledgement via MPLS echo reply.
  b. Old authentication type/key can get unassociated from the session once
the BFD session starts receiving the new authentication type/key.

Still there is one gotcha, which is that MPLS echo reply is unreliable
(i.e., typically an IP routed UDP packet). So there is a chance that MPLS
echo reply can get lost in transit. In addition, we need the receiver to
setup the SW/HW path (in step 2a above). That means the receiver may not be
able to send MPLS echo reply immediate (i.e., ping times out). To protect
from these, we probably want the sender to resent the BFD authentication
change in MPLS echo request if corresponding MPLS echo reply is not
received back.

Note, don't take above texts as is ... sort of wrote this email in a hurry.

Thanks!

-Nobo