Re: [mpls] Adam Roach's No Objection on draft-ietf-mpls-rsvp-shared-labels-07: (with COMMENT)

Vishnu Pavan Beeram <vishnupavan@gmail.com> Thu, 20 December 2018 12:31 UTC

Return-Path: <vishnupavan@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53F13110D; Thu, 20 Dec 2018 04:31:07 -0800 (PST)
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_PASS=-0.001, URIBL_BLOCKED=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 oBsuAZIQGoei; Thu, 20 Dec 2018 04:31:04 -0800 (PST)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 33F69130DF4; Thu, 20 Dec 2018 04:31:04 -0800 (PST)
Received: by mail-pl1-x630.google.com with SMTP id a14so814771plm.12; Thu, 20 Dec 2018 04:31:04 -0800 (PST)
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=rIwosEH6oMr+lvLvJeOZ7hWnNPvl4qJuvyq5Eho3JwI=; b=oIHagg23WYdEasNsjJZ+8MY63p7lU3Ijx14N8UTB22wP7Lsl3EEs6DjLyy7SM+3daA aI541+pn8VllMkjEPB2Ya7VPY36LY0lWzHXCFD8Zk4Ji3pw+Gn4uJeBtcMh2/fz5HJ6V uw3ey+gRubK16m0DZpaojEGk/mptQTgRZniz84vihVq7p1oZhSqfFkSoxa+vJ7cvkgto /C03vuZrsJF9pMzNGsp7afEoJPBf6k+akgg85MxHGLeqitdINPNbf38/0RMlE9YaOqcn GyDhuKIA8VUQouFDyU4tQn0RN+Ne32Io+YjvbeZ2mxfZFU5ZDIkUnLe0Hw/TRgpnSfCA wPOg==
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=rIwosEH6oMr+lvLvJeOZ7hWnNPvl4qJuvyq5Eho3JwI=; b=LSmxIGGTpFC1Mwj+TqLE+zjDKSUhdtWqMlZVR2y7l6UXx4d7uR/rAL9VZaz8fViRtx V6+To876symocb87eiptwaIXERGSdfHQRJav+BN4sMer0eTQQoXDplPbhZvkBr5IsF8N Y+iIup8M1Jhq6G5nS8kW8Ez/sEAuT5eBjJzoe/dPbYbCpkp0qt+6JDcNesJBx6Fk0zQq UnKsaMjBbvNToxYvKIlW5BZ9UnVeolHN9znNoP9kSzYvMXNargm9Phs+679GHT1at7Mg BHygwJ3/8QT7bcbJ62HHmpgecDp3tRVwXeuW27od0JgRT39Z4VPUb50Ym6hFO37BWA5g Ayzg==
X-Gm-Message-State: AA+aEWYb5bGOVjuHsyYiFLv3FiRKB/wV14//8KQMh0OX05k+8PYnO5s2 y0fRAiJZYB5rE9MZDGIKESg7v5yQQytFlkqSTeBsBlKAkBo=
X-Google-Smtp-Source: AFSGD/Uv4ClkznvNyOb3PrQ5Uo39ItcLYfViwzENVQ9hzZYWiDVJOWwsYAYAwq4JsLrlKIGtfEHbDGYrERrbF+l6qjQ=
X-Received: by 2002:a17:902:42e4:: with SMTP id h91mr24395132pld.18.1545309063636; Thu, 20 Dec 2018 04:31:03 -0800 (PST)
MIME-Version: 1.0
References: <154525735582.1826.11425645649794902713.idtracker@ietfa.amsl.com>
In-Reply-To: <154525735582.1826.11425645649794902713.idtracker@ietfa.amsl.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Thu, 20 Dec 2018 07:30:52 -0500
Message-ID: <CA+YzgTtb7M3H1=gmpab3MoL6=gRbf5gsTr7W4DWD0ATKCsGKiQ@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, IETF MPLS List <mpls@ietf.org>, draft-ietf-mpls-rsvp-shared-labels@ietf.org, mpls-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ce6bcc057d734d65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/YBJbZqNx7yXjO7krcoP80-OQasg>
Subject: Re: [mpls] Adam Roach's No Objection on draft-ietf-mpls-rsvp-shared-labels-07: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 20 Dec 2018 12:31:07 -0000

Adam, Hi!



Thanks for the review!

Please see responses inline (prefixed VPB).



Regards,

Pavan

On Wed, Dec 19, 2018 at 5:09 PM Adam Roach <adam@nostrum.com>; wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-mpls-rsvp-shared-labels-07: 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-mpls-rsvp-shared-labels/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to everyone who worked on this document. I have a handful
> of comments.
>
> ---------------------------------------------------------------------------
>
> §7:
>
> >  The following logic could be used by the node constructing the label
> >  stack:
> >
> >     Each RRO label sub-object SHOULD be processed starting with the
> >     label sub-object from the first downstream hop.  Any label
> >     provided by the first downstream hop MUST always be pushed on the
> >     label stack regardless of the label type.  If the label type is a
> >     TE link label, then any label from the next downstream hop MUST
> >     also be pushed on the constructed label stack.  If the label type
> >     is a regular label, then any label from the next downstream hop
> >     MUST NOT be pushed on the constructed label stack.  If the label
> >     type is a delegation label, then the type of stacking approach
> >     chosen by the ingress for this LSP (Section 5.1) MUST be used to
> >     determine how the delegation labels are pushed in the label stack.
>
> The use of normative language in example text is very confusing. I fear
> that
> this processing will be read as normative rather than the example that it
> appears to be ("could be used"). I believe what you want is something more
> like:
>
>       Each RRO label sub-object will be processed starting with the
>       label sub-object from the first downstream hop.  Any label
>       provided by the first downstream hop will always be pushed on the
>       label stack regardless of the label type.  If the label type is a
>       TE link label, then any label from the next downstream hop will
>       also be pushed on the constructed label stack.  If the label type
>       is a regular label, then any label from the next downstream hop
>       will not be pushed on the constructed label stack.  If the label
>       type is a delegation label, then the type of stacking approach
>       chosen by the ingress for this LSP (Section 5.1) will be used to
>       determine how the delegation labels are pushed in the label stack.
>
> Alternately, if the text is meant to be normative, then the introductory
> sentence needs to be changed ("is used" or "must be used"), and the
> paragraph
> itself should probably not be indented.
>

[VPB] Please see our response to Alvaro who had a similar concern. The
above text is meant to be normative. Please see if the proposal in our
response to Alvaro addresses your concern.


>
> ---------------------------------------------------------------------------
>
> §8.1:
>
> >  To provide link protection at a Point of Local Repair (PLR) with a
> >  shared MPLS forwarding plane, the LSR SHOULD allocate a separate TE
> >  link label for the TE link that will be used for RSVP-TE tunnels that
> >  request link protection from the ingress.
>
> This isn't really my area, but from the fuzzy model I have in my head
> about link
> protection, it seems to me that this won't actually work unless a new
> label is
> allocated -- right? If that's the case, then the preceding "SHOULD" would
> appear
> to actually be a "MUST".
>
> Or is the notion that some LSR might choose to simply treat all traffic as
> link-protected?
>

[VPB] Point taken. We'll change this to a "MUST".


>
> ---------------------------------------------------------------------------
>
> §9.2:
>
> >  When a node that does not cater to the mandate
> >  receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object
> >  with this flag set, it MUST send a PathErr message with an error code
> >  of 'Routing Problem (24)' and an error value of 'TE link label usage
> >  failure (TBD3)'.
>
> I'm a little confused about how this is intended to work. At first, this
> looked
> like it might just be a restatement of the behavior of
> LSP_REQUIRED_ATTRIBUTES;
> however, it's unclear how existing, already deployed nodes are going to be
> able
> to send an error value of TBD3.
>
> This same comment applies to §9.4.
>

[VPB] Please see our response to Alvaro and let us know if that addresses
your concern.

This is not a restatement of the behavior of LSP_REQUIRED_ATTRIBUTES.


>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>