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. > > >
- [Teas] Eric Rescorla's No Objection on draft-ietf… Eric Rescorla
- Re: [Teas] Eric Rescorla's No Objection on draft-… Huaimo Chen
- Re: [Teas] Eric Rescorla's No Objection on draft-… Eric Rescorla
- Re: [Teas] Eric Rescorla's No Objection on draft-… Huaimo Chen