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

Lou Berger <lberger@labn.net> Mon, 29 December 2014 15:58 UTC

Return-Path: <lberger@labn.net>
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 F36E81A882D for <teas@ietfa.amsl.com>; Mon, 29 Dec 2014 07:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.232
X-Spam-Level:
X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 aBrbi8w61JQy for <teas@ietfa.amsl.com>; Mon, 29 Dec 2014 07:58:22 -0800 (PST)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id BABB61A87C2 for <teas@ietf.org>; Mon, 29 Dec 2014 07:58:22 -0800 (PST)
Received: (qmail 13314 invoked by uid 0); 29 Dec 2014 15:58:17 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 29 Dec 2014 15:58:17 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id ZTy81p0012SSUrH01TyBpK; Mon, 29 Dec 2014 08:58:18 -0700
X-Authority-Analysis: v=2.1 cv=fJeqg/qe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=xSRs65CQCjkA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=JtdKPrM4gIBQURarXsoA:9 a=QEXdDO2ut3YA:10 a=2JOtklbuwVsA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=agOlZoFEIuLHSlGTzbQpFqkOUUZMHgqfvILHsqyzWlI=; b=iKelSlojWbVQQpcsNU/gve6+ScGfOxMmiH9wADY3i+MXIeJdPMWIptkFXHFpKQIH1eeL7qHoMWDRoyjvXM3OavQKStlYvuOTCHJRCavQfSskq3FJKETkbrZ1qoC3G73r;
Received: from box313.bluehost.com ([69.89.31.113]:54043 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from <lberger@labn.net>) id 1Y5chq-0002Kz-L4; Mon, 29 Dec 2014 08:58:07 -0700
Message-ID: <54A17A0A.6030305@labn.net>
Date: Mon, 29 Dec 2014 10:58:02 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/teas/EIFhFe-7I75Ed1e5CS1rtirD3n0
Cc: TEAS WG <teas@ietf.org>
Subject: [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: Mon, 29 Dec 2014 15:58:24 -0000

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.

>>> 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".

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"?

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

Thank you,
Lou