IETF Logo Mail Archive

Comments on draft-katz-yeung-traffic-08.txt

Acee Lindem <acee@REDBACK.COM> Thu, 17 October 2002 20:00 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24407 for <ospf-archive@LISTS.IETF.ORG>; Thu, 17 Oct 2002 16:00:07 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007791CE@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 16:02:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307545 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 16:02:18 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 16:02:17 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 660F01DCC60; Thu, 17 Oct 2002 13:02:16 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3DAF1747.9060504@redback.com>
Date: Thu, 17 Oct 2002 16:02:15 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Comments on draft-katz-yeung-traffic-08.txt
Comments: To: IETF Traffic Engineering WG <te-wg@ops.ietf.org>
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Comments:

     - The LSA Header Diagram in section 2.3.1 does not reflect
       the fact that the instance has been extended to 24 bits.

     - Section 2.4.1 - Replace "but for obvious reasons this..."
       with "but this nomenclature is avoid here since the
       OSPF router ID is not necessarily a routable address."

     - Section 2.5.4 - Why 0.0.0.0 for the remote address for
       multiaccess links? It seems the TLV should either be
       omitted or set to the single neighbor address (since
       section 1.2 limits traffic engineering to multiaccess
       networks with 2 devices).

Suggestion:

       - Include "Implications on Graceful Restart" section
         similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt.
         Explicitly state that the goal is to maintain
         existing traffic engineered paths while discouraging
         any new ones until reservation state is obtained.

Thanks,
--
Acee

v2.23.0 | Report a Bug | By Email