Re: [Teas] Eric Rescorla's No Objection on draft-ietf-teas-rsvp-egress-protection-15: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Thu, 08 March 2018 04:33 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB0F1201FA for <teas@ietfa.amsl.com>; Wed, 7 Mar 2018 20:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 t4fzfy9AejJa for <teas@ietfa.amsl.com>; Wed, 7 Mar 2018 20:33:46 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 A4FBC12D80E for <teas@ietf.org>; Wed, 7 Mar 2018 20:33:45 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id t6so5377222qtn.9 for <teas@ietf.org>; Wed, 07 Mar 2018 20:33:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QjCfL3gHjQNVv+TXXrz3iqd0js7yljZnIh2+LZjMEWc=; b=GWOI358pbzwH2rysO9gARzfYUv/0bWCkYkEMr5956OdvsS6RuJdj7QM6bl6qjdC28O EvmSFFY/oi+oUnCxNDYj1N0ckuRCMt2rtbg4W/dWgZfwkzZ3mMehmH6Kx5PyIdYggZXB dpQq47gLoUVWx2AIlY/ExFzXnO8wSsYweqRrVrx2viyoj27tsiCzjEST4lrR0DGEM93d H0Cv/Jbb8hTZC9MqMi2EQn4Wgo5pIo3H8mLrQhj98vC9YFw9ZtPEYevlhTmdLiUELhUc ZicEwfafEH7yADw4sYy8lvHMycAQjHlSav4sRxm8uF1BH2Fp2bUFbXUdDYU7fNcD58pz 2jCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QjCfL3gHjQNVv+TXXrz3iqd0js7yljZnIh2+LZjMEWc=; b=UXftV0GElzM0iq3b+jWcI2rQof0ZIuhiguEwrq7cIMxGprAqNtjAZyPnp6v4kMLImq fS+be/X9wGsatoW3Ar1TaJX87hCAdjnC49kygUlKe9SWGtKt/jLlbgGsTGHFx8zi6g/8 iTD7s4lPa0b6Q5YHbRp8WtKpJjYDDi811Ji1Pm5v/qmBKc3HkISo3VbPMAGAXzBfz/Jq uCDKSQZcIKwTBZV9MpnPKFibA0MnfVcX1AKwcJrGjmsaoYOqpouyLz37N8demZ9AXaa6 60TeAAiOqav4nKl5XCCySA8gyb9XoQGEmsLsssY+Qt7spKWV6pxBCT0BuyXqiutmCLUy f1bA==
X-Gm-Message-State: AElRT7FmPSOht44BTt/YwX2jS6yszTtHkXwQtvALqRTxTxdCYaEU8XLm v0RrHF2oRjveboabtHFTIVamb2B73szL08jbWLWBlg==
X-Google-Smtp-Source: AG47ELt5+Sed+zBTXggHpLTHD7mJS+1vO9fOGlTRZYvgPfMUKjyUCJwJsLrplYW+VHAfbsmKrL0EI1NodG77heX9jfg=
X-Received: by 10.200.42.177 with SMTP id b46mr38606182qta.321.1520483624719; Wed, 07 Mar 2018 20:33:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Wed, 7 Mar 2018 20:33:04 -0800 (PST)
In-Reply-To: <5316A0AB3C851246A7CA5758973207D463A584E2@sjceml521-mbs.china.huawei.com>
References: <152047594343.21248.12956511410896389971.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D463A584E2@sjceml521-mbs.china.huawei.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 07 Mar 2018 20:33:04 -0800
Message-ID: <CABcZeBNCDOqrE1y4ND+j9Rb=YmwvLw0JzAnO8S1NQHkXoNizTA@mail.gmail.com>
To: Huaimo Chen <huaimo.chen@huawei.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-teas-rsvp-egress-protection@ietf.org" <draft-ietf-teas-rsvp-egress-protection@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "vishnupavan@gmail.com" <vishnupavan@gmail.com>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="001a113b032856ad290566df2ef5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/oxFqTUpb-WQaZXFF62rV9IxRqxs>
Subject: Re: [Teas] Eric Rescorla's No Objection on draft-ietf-teas-rsvp-egress-protection-15: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2018 04:33:49 -0000

On Wed, Mar 7, 2018 at 8:27 PM, Huaimo Chen <huaimo.chen@huawei.com> wrote:

> Hi Eric,
>
>     Thank you very much for your time and valuable comments.
>     Answers to them are inline below with prefix [HC].
>
> Best Regards,
> Huaimo
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Wednesday, March 07, 2018 9:26 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-teas-rsvp-egress-protection@ietf.org; Vishnu Beeram <
> vishnupavan@gmail.com>; teas-chairs@ietf.org; vishnupavan@gmail.com;
> teas@ietf.org
> Subject: Eric Rescorla's No Objection on draft-ietf-teas-rsvp-egress-protection-15:
> (with COMMENT)
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-teas-rsvp-egress-protection-15: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> https://mozphab-ietf.devsvcdev.mozaws.net/D4328
>
> I found this document a little hard to follow because it took me a while
> to understand the difference between the current situation and the change
> in the draft. Would you consider putting part of the material from S 6 in
> the introduction so non-experts could have more context?
> [HC]. Yes. We will consider putting some details in the introduction.
>
>
>    locally protecting the egress node(s) of an LSP.
>
>    This document fills that void and specifies extensions to RSVP-TE for
> For those of us who are not experts, can you say what "protecting" means?
> [HC] Yes. In general, locally protecting an egress node of an LSP
> means that when the egress node fails, the traffic that the LSP carries
> will be delivered to its destination continually by the direct upstream
> node
> of the egress node and the backup egress node.
> Without protecting the egress node of the LSP, when the egress node
> fails, the traffic will be lost (i.e., the traffic will not be delivered
> to its destination).
>
>
Sorry, I apologize for being unclear. I meant perhaps you could say it in
the intro.


>    egresses L1 and L2 of a primary P2MP LSP from ingress R1 to two
>    egresses L1 and L2.  La and Lb are the designated backup egresses for
>    primary egresses L1 and L2 respectively.  The backup LSP for This might
> be the tiniest bit confusing, as it mentions L1 and L2 twice.
> [HC] We will revise the related text accordingly as below:
> egresses L1 and L2 of a primary P2MP LSP starting from ingress R1.
>
>
>    The exact mechanism by which the failure of the primary egress is
>    detected by the upstream node is out of the scope of this document.
> It would be helpful for me if you specified what the upstream node is. Is
> it R3?
> [HC] Yes. We will specify it according to your suggestion as follows:
> The exact mechanism by which the failure of the primary egress node is
> detected by the upstream node R3 is out of the scope of this document.
>
>
>    node does not provide any fast local protection against the failure
>    of the primary egress node.  In this case, the backup LSP from the
>    branch node to the backup egress node protects against failures on This
> sentence would be clearer if it said "If the direct upstream node does not
> provide any fast local protection ....."
> [HC] We will update the related text accordingly as below:
> If the direct upstream node does not provide any fast local protection
> against the failure of the primary egress node, the branch node can be
> a (upstream) node on the primary LSP, but not the direct upstream node.
>
>
>    the subobject in bytes, including Type, Length and Contents fields.
>    The Reserved field MUST be set to zero.
> What are the semantics of the optional subobjects?
> [HC] A optional subobject means that this subobject is optional (i.e.,
> this subobject may be there or may not be there).
>

Sorry, I got that. I mean, what are the semantics if those are present.

-Ekr


>
>
>    To protect the VPN traffic against the failure of the egress L1 of
>    the LSP, an existing solution (refer to Figure 2) includes:
> I wasn't reading this closely, so it took me a minute to be like "hold on,
> this is reroute from R1, nor R3". Probably just me being stupid, but it
> might have helped to have a subsection like "Existing solution before this
> draft"
> [HC] Yes. It is reroute by R1 instead of R3. We will update the related
> text
> accordingly as follows:
> To protect the VPN traffic against the failure of the egress node L1 of
> the LSP, when the egress node fails, the ingress R1 of the LSP does
> the reroute in an existing solution (refer to Figure 2). The solution
> includes:
>
>
>        The PLR R3 is closer to L1 than the ingress R1.  It may detect
>        the failure of the egress L1 faster and more reliable.  Thus we
>        can have faster protection for egress.
> Nit: "more more reliably"
> [HC] We will update the related text accordingly.
>
>
>