Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (with COMMENT)

Vishnu Pavan Beeram <vishnupavan@gmail.com> Thu, 08 March 2018 15:47 UTC

Return-Path: <vishnupavan@gmail.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 33C99126FDC; Thu, 8 Mar 2018 07:47:29 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 fsqVB7TQl0tK; Thu, 8 Mar 2018 07:47:26 -0800 (PST)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (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 76367126DFB; Thu, 8 Mar 2018 07:47:26 -0800 (PST)
Received: by mail-pl0-x22e.google.com with SMTP id 9-v6so3514364ple.11; Thu, 08 Mar 2018 07:47:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ItY2WuyLW6Bd4Nv2zdCO/tCFFFMBQSj5XItT7hP0K4I=; b=FEXOXJ3l0GD+n39YaFwAsuLZCGaLfT3nTX+r4iN2tuG0Gy6wOK/A50/vyD1udMYEwj jtMzXnKl8cBY2H3bYALCyZ66dtQZeTvtTRfUo9nFdibyAcEvYhzoNK/NXDMgm4nFJTP+ YpOycyWj85LNIXRdpPBpl/vZ+Gjmdkg/NhJMdQ8bGsg2N85CoKbAHdOE/91GswdqOqoN kmDLOK4wMytF54tJEqk/0XDebBwKuSLS5MKxmmu+AxHEJWOuRvR1m0sLWsZVRQ6rwd9T 0xNBrWPlK4MMSeOP5o80XNd0CwoCCk64N6+kFsBWLYC7wMoWOKAvA404Ct4f3VTvZQsB fN0Q==
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=ItY2WuyLW6Bd4Nv2zdCO/tCFFFMBQSj5XItT7hP0K4I=; b=NhDXISACsZ2YE8B6RLBrJ3tLP8QgmmT41e/Dvz1KIKDt99qYbYFtZjEu96AWp/dOcf 215M2D/ZKrnVd2K+mFKohbsLgdev/NTyU0R8b+gKKJDyLfUKOz0dzBGlfO3MxJYGF9Cw DlxXL56zJ59c7MaprqAz37txn7QnWaEAbe+QZF2iPy76jIgKmrxmnr4VZzC4TtOXa/6o BriOTm4dDVroq1uil1HrOdUEvEJbfsq15D4tj/pWrVbvXJO6HqBLF5UDu2pKScIzndCQ kzQTXtnWwi/WBw4toRNB8sZNZHfLAXDoEgoE1yfk6AGz0C1n0986IYSa8/NNb3E4wkSJ tdfg==
X-Gm-Message-State: APf1xPCukyD+lnGcXiRJDCiiLiAmdhkYnGuzdtDq5aRv0ix3zw9G0/8M rHTa50LCxGXrePEiSnIkS8d+wr59yefwGtIhxOY=
X-Google-Smtp-Source: AG47ELtA5ioJTc5SD2ob63vP7yCedQVv4BROZRlrpceBwDbmdL5GLFzYnFsish+Bi4yHchQsDfGJww2AT0ud50tvi/M=
X-Received: by 2002:a17:902:b606:: with SMTP id b6-v6mr23929070pls.93.1520524045937; Thu, 08 Mar 2018 07:47:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.160.6 with HTTP; Thu, 8 Mar 2018 07:47:25 -0800 (PST)
In-Reply-To: <CAMMESsy85F0J68MbtsjKDGbVvZZ35+hv7XjOGzzMvCr8fbsZOQ@mail.gmail.com>
References: <152037120319.28250.13326911149440960090.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D463A57F2A@sjceml521-mbs.china.huawei.com> <CA+YzgTtf-Kca766ttgCEnGhRUNVHiToGivZbnwLvKH0GicTo4g@mail.gmail.com> <CAMMESsy85F0J68MbtsjKDGbVvZZ35+hv7XjOGzzMvCr8fbsZOQ@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Thu, 08 Mar 2018 10:47:25 -0500
Message-ID: <CA+YzgTuwRZ=4QcBA4GD1BYFJCNZjP05XZLjexP-1+5F_hKPoDw@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: Huaimo Chen <huaimo.chen@huawei.com>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Vishnu Beeram <vbeeram@juniper.net>, The IESG <iesg@ietf.org>, "draft-ietf-teas-rsvp-ingress-protection@ietf.org" <draft-ietf-teas-rsvp-ingress-protection@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a173050566e897a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/TDQ-JC8CzqUT4v8AjgW8UydoWJM>
Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-ingress-protection-16: (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 15:47:29 -0000

Alvaro, Hi!

Please see inline..

Regards,
-Pavan

On Wed, Mar 7, 2018 at 5:07 PM, Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> On March 7, 2018 at 3:48:03 PM, Vishnu Pavan Beeram (vishnupavan@gmail.com)
> wrote:
>
> Pavan:
>
> Hi!
>
> ...
>
>
>> (2) The IANA Considerations Section still needs some work.  I know that
>> the authors have been in conversations with IANA (IESG was cc'd) and that
>> the result is to add the "This document does not request any IANA actions"
>> text.
>>
>> However, to avoid confusion it would be better if the IANA Considerations
>> section only contained that text, and a new Section (maybe "Class Name and
>> Number") was added to include the current text.
>>
>> (2.1) About the current text...  I find the text about the Class Number a
>> little confusing as in the end it doesn't matter which Private Use range is
>> used; and the use of Normative Language...  Suggestion:
>>
>> OLD>
>>    The assignment of a new Class Name and corresponding 8-bit Class
>>    Number data object in an RSVP message is defined in ([RFC3936]) with
>>    ranges for Standards Action, Expert Review, and Reserved for Private
>>    Use. The Private Use ranges can be used for experimental use, they
>>    will not be registered with IANA and MUST NOT be mentioned by RFCs.
>>
>>    It is suggested to use the following Private Use range:
>>
>>      o  124-127 Reserved for Private Use
>>
>>    It is for an experimental implementation to choose a value from the
>>    Private Use range, and to agree with cooperating implementations
>>    participating in the same experiments what values to use.
>>
>> NEW>
>>    The IANA Registry for Class Numbers created by [rfc3936] didn't define
>> a
>>    range to be used for Experimental Use [rfc8126]; instead several
>> Private Use
>>    ranges exist.  It is suggested that a value from a Private Use range
>>    (124-127 for example) be chosen for experimentation.
>>
>
> [VPB] RFC3936 does specify three "Expert Review" ranges for Class Numbers
> which can be used for experimental use. However, upon reviewing this
> document, the experts (teas-chairs, in this case) decided that a value from
> the "Private Use" range is more apt for this experiment. There are three
> "Private Use" ranges specified in RFC3936 -- the compatibility rules
> associated with the object (RFC2205, Section 3.10) determine which specific
> range to use. As per the compatibility aspects specified in Section 7 of
> this document, a value from the range 124-127 should get used.
>
> Please see if the following text addresses your concerns with regards to
> the IANA section.
> **
> This document does not request any IANA actions.
>
> This document defines one new object to indicate ingress protection.
> -  INGRESS_PROTECTION
>
> The assignment of a new Class Name and corresponding 8-bit Class
> Number for an object in an RSVP message is defined in [RFC3936] with
> ranges for Standards Action, Expert Review, and Private Use. Values
> chosen from the Private Use range are not registered with IANA.
> Since, the Class Number for this object must be of the form 0bbbbbbb
> (refer to Section 7 on compatibility aspects), it is suggested that a value
> from the Private range [RFC3936] for this form (124-127) be chosen
> for experimentation.
>
> **
>
> Yes, I overlooked the 0bbbbbbb part in S7.
>
> I don’t think the first part of your suggested text is needed (mentioning
> the different registration procedures) because it may cause confusion.  The
> rest is fine with me.
>
> I still would like to see two separate sections.
>
> Thanks!
>
> Alvaro.
>
[Pavan] I missed your comment on having separate sections. I'm in total
agreement with you on the suggested changes. The authors have been asked to
keep the IANA section simple (just one statement saying that no specific
IANA action is required) and make relevant consequent changes (listed
below) to the document.

**
(1). In Section 4.1, remove the following line at the top of Page 9:

  Class-Num = TBD      C-Type = 1 for INGRESS_PROTECTION_IP

--
(2). Insert a new Sub-Section under 4.1:

4.1.1.  Class Number and Class Type

The Class Number for this object MUST be of the form 0bbbbbbb to
enable implementations that do not recognize the object to reject the
entire message and return an "Unknown Object Class" error [RFC2205].
It is suggested that a Class Number value from the Private Use range
(124-127) [RFC3936] specified for the 0bbbbbbb octet be chosen
for this experiment.  It is also suggested that a Class Type value of 1
be used for this object in this experiment.

--

(3) Replace all occurrences of "sub object" with “subobject” in the document

--

(4). There is some weirdness surrounding how CTYPE and Subobject Type are
mentioned interchangeably in this document. We would need to fix all of
that. You need just one CTYPE and multiple Subobject types. Please make the
following change in the sub-section "Subobject: Backup Ingress IPv4 Address”

OLD:
The Type of the sub object is TBD1 (the exact number to be assigned by
IANA), and
   the body of the sub object is given below:

NEW:
The Type of the subobject is 1, and the body of the subobject is as given
below:

--

(5). Make the following change in the sub-section "Subobject: Backup
Ingress IPv6 Address”

OLD:
The Type of the sub object is TBD2, the body of the subobject is given
below:

NEW:
The Type of the subobject is 2, the body of the subobject is as given below:

--

(5). Make the following change in the sub-section "Subobject: Ingress IPv4
Address”

OLD:
The Type of the sub object is TBD3.

NEW:
The Type of the subobject is 3.

—

(6) Make the following change in the sub-section “Subobject: Ingress IPv6
Address”

OLD:
The Type of the sub object is TBD4.

NEW:
The Type of the subobject is 4.

—

(7). Make the following change in the sub-section “Subobject: Traffic
Descriptor”

OLD:
The Type of the sub object is TBD5, TBD6, TBD7 or TBD8 for Interface, IPv4
   Prefix, IPv6 Prefix or Application Identifier respectively.

NEW:
The subobject types for Interface, IPv4 Prefix, IPv6 Prefix and Application
Identifier are 5, 6, 7 and 8 respectively.

—

(8) Remove all other uses of (Type TBD) in the sub-section “Subject:
Traffic Descriptor”

—

(9) Make the following change in the sub-section “Subject: Label-Routes"

OLD:
The Type of the sub object is TBD9.

NEW:
The Type of the subobject is 9.

—

(10) Make the following change in the “Compatibility” Section:

OLD:
One new object is defined to indicate ingress protection with class numbers
in the form 0bbbbbbb.

NEW:
The new object defined to indicate ingress protection has a class number of
the form 0bbbbbbb.

—

(11) Make the following change to the IANA section (just one statement as
per Alvaro’s suggestion):

IANA Considerations

This document does not request any IANA actions.

--