Re: [Teas] OPS-DIR Review draft-ietf-teas-rsvp-te-domain-subobjects

Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 07 December 2015 06:04 UTC

MIME-Version: 1.0
Sender: dhruvdhody@gmail.com
In-Reply-To: <6F154112-526C-46C5-8B39-78F0819A91E0@jvknet.com>
References: <5650CCAC.3090702@jvknet.com> <CAB75xn7C215vZtWGdz4K7+gKO0-RZX3v4XXmpyY8Lj=eTSb8HQ@mail.gmail.com> <6F154112-526C-46C5-8B39-78F0819A91E0@jvknet.com>
Date: Mon, 07 Dec 2015 11:34:16 +0530
Message-ID: <CAB75xn7qtYr_QHJBzn35+aqqZ5GQ9akUvO4J3E7zV4kwH71mDA@mail.gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
To: Victor Kuarsingh <victor@jvknet.com>
Content-Type: multipart/alternative; boundary="089e011827589243ae052648a00f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/mcV2lEsWw40lRrmgeSt-zOqF_7o>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "BRUNGARD, DEBORAH A" <db3546@att.com>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>, Vishnu Pavan Beeram <vbeeram@juniper.net>, Joel Jaeggli <joelja@bogus.com>, "dhruv.dhody@huawei.com" <dhruv.dhody@huawei.com>, Benoit Claise <bclaise@cisco.com>, Lou Berger <lberger@labn.net>, "draft-ietf-teas-rsvp-te-domain-subobjects.all@ietf.org" <draft-ietf-teas-rsvp-te-domain-subobjects.all@ietf.org>
Subject: Re: [Teas] OPS-DIR Review draft-ietf-teas-rsvp-te-domain-subobjects
Precedence: list

Hi Victor,

<adding TEAS>

Regarding the open issue with the use of word "advised" v/s "SHOULD" at -

OLD:
      For the purpose of this experiment, it is advised to use
      4-Byte AS number subobject as default.
SUGGESTED:
      For the purpose of this experiment, 4-Byte AS number
      subobject SHOULD be used as default.

The AD, chairs and authors discussed, though we can go either way, *but*
for an experimental draft to use the word "advised" seems appropriate. In
case this was on standards track use of SHOULD would be required.
To *advise* how to run an experiment seems more appropriate than the use of
"SHOULD".  Would you be okay with text if kept, as it currently is?

WG,
This is the only open issue, the document is ready to be sent to RFC
editor after this.
https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-05

Regards,
Dhruv


On Wed, Nov 25, 2015 at 9:27 AM, Victor Kuarsingh <victor@jvknet.com> wrote:

> Dhruv,
>
> Yes,  that looks good.
>
> Regards,
>
> Victor K
>
> Sent from my iPad
>
> On Nov 23, 2015, at 12:03 AM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>
> Hi Victor,
>
> Thanks for your review. Please see inline...
>
> On Sun, Nov 22, 2015 at 1:27 AM, Victor Kuarsingh <victor@jvknet.com>
> wrote:
>
>> Dear Authors,
>>
>> I have reviewed this document as part of the Operational directorate's
>> ongoing effort to review all IETF documents being processed by the IESG.
>> These comments were written with the intent of improving the operational
>> aspects of the IETF drafts. Comments that are not addressed in last call
>> may be included in AD reviews during the IESG review.  Document editors and
>> WG chairs should treat these comments just like any other last call
>> comments.
>>
>> Document Reviewed - draft-ietf-teas-rsvp-te-domain-subobjects-03
>> Link to Document -
>> https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-03
>>
>> Summary:
>>
>> This document outlines an experimental set of new sub-objects within the
>> RSVP-TE / GMPLS framework which includes 4-byte Autonomous Systems and
>> Interior Gateway Protocol Area (IGP) during path setup. The new ERO
>> (Explicit Route Objects), XRO (Exclude Route Object) and EXRS (Explicit
>> Inclusion Route) sub-objects are defined within the document, including the
>> mode of operation in how they are to be used.
>>
>> General Comments and Feedback:
>>
>> Backwards compatibility is generally address by reference to RFC3209
>> which describes behavior of implementations which do not yet have these new
>> sub-objects defined (i.e. PathErr).  This behavior is both expected and
>> valid.
>>
>> In section 3.2.1, when defining the behavior of nodes which support this
>> new 4-byte option capability, it is suggested that the 4-byte sub-objected
>> be used for both 2-byte and 4-byte ASs information transfer.  It's
>> understand that this document is designated for Experimental, so
>> operational challenges which can arise may be better suited for review when
>> an Standard-Track document is released, however, I would suggested that we
>> consider making it a MUST or  SHOULD by default.  I would also think that
>> one may consider saying that if the 4-byte sub-option is used, then the
>> 2-byte sub-option should not be used at the same time (although the
>> information would be consistent (likely), it's my opinion that the same
>> information not be advertised at the same time using two different options.
>> (point of consideration, not a must).
>>
>
>  [Dhruv]: So that it's clear on what change is being requested...
> OLD:
>       For the purpose of this experiment, it is advised to use
>       4-Byte AS number subobject as default.
> SUGGESTED:
>       For the purpose of this experiment, 4-Byte AS number
>       subobject SHOULD be used as default.
>
> Chairs/AD - what do you think?
>
> Second, say you want to encode AS 100 in ERO, you would include it as
> 0x0064 in 4-byte AS or as 0x64 in 2-byte AS. You would have to pick between
> one of these, both would not be included. If it's okay with you I would
> prefer to not make any text change for this.
>
> Regards,
> Dhruv
>
>
>
>> Textual Review:
>>
>> No specific text changes were / are suggested from this review.
>>
>>
>>
>

Re: [Teas] OPS-DIR Review draft-ietf-teas-rsvp-te… Dhruv Dhody