Re: [Pce] Genart last call review of draft-ietf-pce-stateful-path-protection-08

Mahend Negi <mahend.ietf@gmail.com> Sat, 31 August 2019 09:31 UTC

Return-Path: <mahend.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01872120048; Sat, 31 Aug 2019 02:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Xrk6XiMCJKdS; Sat, 31 Aug 2019 02:31:20 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 C9175120046; Sat, 31 Aug 2019 02:31:20 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id l2so7261750oil.0; Sat, 31 Aug 2019 02:31:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dGH1wjkLMBR+USsdqqpK+nYvT4ioMv/ja8tyr1qeurw=; b=QFBgfB/Z3VF1KQwgoFZikaQIgk+ZPlkGkXV9BP513pliVr0u9ahGKP6SLKTMtSVcNT 7oJt9zLn2nF4Vr0gPXYFYMRg27k8emWSgD8FY3qN8m/eWhIMUccgLtvAK5sUUhYoFFux T8+yvgPfiH/VpQaBRT/g26pToF8lMQ4U3GqNhUaG7C1Nx949bth3zkdxXDLllCiU3Krq Oblad7dJ0ZQrU3SesI1wYQW5cWAng41o+0duWrEQIOcyrQbjm2TuNKBhuySYDMwLig9i JMZ+z1qKJZCxSJQ3k4OI4ZeGp9WVGUV+Tsp9QdLol5cXmMcVA1cG4AjvvPTuzUxM2Tz3 jeGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dGH1wjkLMBR+USsdqqpK+nYvT4ioMv/ja8tyr1qeurw=; b=lRI99F46AkbVN+Tf+YuYHsdG5dGpaxF4ZfbHi7Qfg1Kk/yNNlgTLKRAUdnoMaNZUm+ KTytRq7EvS1AO0/G6YWOgtjBbnzBCpeMh8o8d+07kvQXdWPBWp1fCf2up/7aGU6q/Xn5 wAFZ4ZlxFXTikqzUu3o+MQXBA82SZSxSp8c2Y49rKRO9IqhmJSz1IiDrjl7uKrpbNFFJ pSy5uRHWoboi0jbuVLFl9fIi7hqRAorcz29y8NBRmzPUAmhr7qXGbXUBKPN7036VGfgc vHMEhJCiKielR1KGa1JZdCcthpmrrlh/bSDpWGbjFx2TLP0uY+r+5nFR6TvhOXkrsZBd sTxw==
X-Gm-Message-State: APjAAAWObi/mhxNz0DN/kg6L1sSH7mxd115v8qgCICKJfEa/dNQ/VCgy JcJ25STOtLRfUSNUZzaZgvHQzOLRXIh4FCwtbw4=
X-Google-Smtp-Source: APXvYqz6qHyRic/87ky9Ju9M0/SvK7BIHPkH6QAKc4/umM+HeeU4AH5xC6smzeN2KEMPM4MmSrJIs7JUS+zwKFO7BpI=
X-Received: by 2002:aca:6742:: with SMTP id b2mr13069474oiy.14.1567243880107; Sat, 31 Aug 2019 02:31:20 -0700 (PDT)
MIME-Version: 1.0
References: <156704789212.1265.12949882127746399605@ietfa.amsl.com> <CAB75xn5aTWMUy1JonEe6LSBjiG4_uYFy0rt5ea68E2mFjthUOQ@mail.gmail.com>
In-Reply-To: <CAB75xn5aTWMUy1JonEe6LSBjiG4_uYFy0rt5ea68E2mFjthUOQ@mail.gmail.com>
From: Mahend Negi <mahend.ietf@gmail.com>
Date: Sat, 31 Aug 2019 15:01:09 +0530
Message-ID: <CAM5Nu_wwfr=k25MPu3S=Jw=38ERH=sAN=eqkh_QRecvdhvp+Kg@mail.gmail.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, resnick@episteme.net
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-pce-stateful-path-protection.all@ietf.org, pce@ietf.org, "ietf@ietf.org Discussion" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c013030591666603"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/m9phQBO6hbyKnVJGk0jt5TywmOI>
Subject: Re: [Pce] Genart last call review of draft-ietf-pce-stateful-path-protection-08
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Aug 2019 09:31:23 -0000

Hi Dhruv/Pete,

Thanks for the review, new version handles the comments.

FYI:
New Version:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-path-protection
Diff             :
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-path-protection-09

Thanks,
Mahendra

On Thu, Aug 29, 2019 at 3:47 PM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

> Hi Pete,
>
> Thanks for your review and nits. Just snipping to two points...
>
> > OLD
> >      |   PT      |     Path Protection Association Flags         |S|P|
> > NEW
> >      |   PT      |                Unassigned                     |S|P|
> >
>
> I feel it is important to keep the name "flags" in the figure to match
> with the text following the figure. Also this seems to be our usual
> practice in past documents as well. We can change to just "flags" if
> you would prefer that?
>
> For context ->
>
>    The format of the Path Protection Association TLV (Figure 1) is as
>    follows:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |         Type = TBD2         |              Length             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   PT      |     Path Protection Association Flags         |S|P|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>              Figure 1: Path Protection Association TLV format
>
>    Path Protection Association Flags (32 bits) - The following flags are
>    currently defined -
>
>       Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
>       [RFC4872] to indicate if the LSP is working or protection LSP.
>
>       Secondary (S): 1 bit - This bit is as defined in Section 14.1 of
>       [RFC4872] to indicate if the LSP is primary or secondary LSP.  The
>       S flag is ignored if the P flag is not set.
>
>       Protection Type (PT): 6 bits - This field is as defined in
>       Section 14.1 of [RFC4872] to indicate the LSP protection type in
>       use.
>
>       Unassigned bits are considered reserved.  They MUST be set to 0 on
>       transmission and MUST be ignored on receipt.
>
>
> > Section 6:
> >
> > At the top of the section, I suggest putting in the following:
> >
> > [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1"
> through
> > "TBD5" those should be replaced by the values that IANA assigns. Also,
> Section
> > 4.5 includes several occurrences of the phrase "(Early allocation by
> IANA)";
> > please confirm that the value mentioned there is correct and delete that
> phrase
> > from the document before publication.]
> >
>
> I would suggest the authors to remove the phrase "(Early allocation by
> IANA)" in the document now as the referenced draft is in RFC-EDITOR
> queue and the early allocation tag is removed in the IANA page -
> https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects
>
> Thanks!
> Dhruv
>