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

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Dec 2015 11:34:16 +0530

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 <[email-masked]> wrote:

> Dhruv,
>
> Yes,  that looks good.
>
> Regards,
>
> Victor K
>
> Sent from my iPad
>
> On Nov 23, 2015, at 12:03 AM, Dhruv Dhody <[email-masked]> wrote:
>
> Hi Victor,
>
> Thanks for your review. Please see inline...
>
> On Sun, Nov 22, 2015 at 1:27 AM, Victor Kuarsingh <[email-masked]>
> 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.
>>
>>
>>
>