Re: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb

"Dongjie (Jimmy)" <jie.dong@huawei.com> Tue, 30 December 2014 02:27 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F01ABC0F for <teas@ietfa.amsl.com>; Mon, 29 Dec 2014 18:27:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 iDC-O8ecR7Hs for <teas@ietfa.amsl.com>; Mon, 29 Dec 2014 18:27:14 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CDE1A9034 for <teas@ietf.org>; Mon, 29 Dec 2014 18:27:13 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQQ01604; Tue, 30 Dec 2014 02:27:12 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Dec 2014 02:27:10 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.128]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 30 Dec 2014 10:27:03 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Lou Berger <lberger@labn.net>, "draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org" <draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org>
Thread-Topic: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb
Thread-Index: AQHQI4BM8rhPgmrsKEu1O1NWggWFRpynYi8A
Date: Tue, 30 Dec 2014 02:27:02 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927337F121B@nkgeml512-mbx.china.huawei.com>
References: <54A17A0A.6030305@labn.net>
In-Reply-To: <54A17A0A.6030305@labn.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.96.76]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/teas/YAxK2tQr0i-jN8RgaiFuAhdQc48
Cc: TEAS WG <teas@ietf.org>
Subject: Re: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 30 Dec 2014 02:27:16 -0000

Hi Lou, 

Thanks a lot for pointing out these comments, I just submitted a new revision (-01) to solve all of them. 

And please see my replies inline: 

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Monday, December 29, 2014 11:58 PM
> To: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org
> Cc: TEAS WG
> Subject: [Teas] progressing draft-ietf-teas-rsvp-te-li-lb
> 
> Authors (WG),
>     I'm the shepherd for this document.  I was hoping to put in the
> publication request for this document today as it would have been nice to have
> a publication request in 2014! Unfortunately, I see some comments that were
> not addressed from before the LC.  In particular, from the thread starting with
> http://www.ietf.org/mail-archive/web/ccamp/current/threads.html :
> 
> >From: Dongjie (Jimmy):
> >...
> >>From: Lou Berger
> >...
> >> WRT section 2.1.  Extensions for Lock Instruct:
> >> - What extension is defined in this subsection.  What do you think
> >> about replacing section 2.1 with something along the lines of?
> >>
> >>   2.1. Lock Instruct Indication
> >>
> >>    In order to indicate the lock/unlock of the LSP, the A
> >>    (Administratively down) bit in ADMIN_STATUS object [RFC3471]
> >>    [RFC3473] is used.
> >>
> >
> > Agree with your suggestion. This could make section 2.1 much clearer.
> 
> I think this means that the object format and bit definitions are to be removed.

Yes, my intention was to remove them, but somehow they were kept in the previous version. Now they are removed.

> >>> Where is the Loopback (B) bit / Attribute Flag defined? This
> document, right?
> ...
> >> This said, you still need to mention where it is defined (e.g., in
> section 3.1, add
> >> "defined above" the first time you mention the bit) and add it to the
> IANA
> >> section.
> >Will fix this in the new revision.
> 
> You still use "(B)" in Section 3.2, but nowhere else. Please replace all instances
> of "Loopback (B) bit" and "Loopback flag" with "Loopback Attribute Flag".

Now they are substituted by "Loopback Attribute Flag".

> Finally, WRT the discussion on 2119 language, there is also one more "SHOULD"
> I have a question about:
>    When an LSP is put in lock mode, the subsequent Path and Resv
>    messages SHOULD keep the A bit in ADMIN_STATUS Object set.
> 
> Why isn't this a "MUST"?

Good catch. Have changed this one and another "SHOULD" in similar case to "MUST".

> That's it, please let us/me know when to expect the next revision.

The new revision has just been submitted. Sorry for any inconvenience caused.

Many thanks,
Jie

> Thank you,
> Lou
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas