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

Kireeti Kompella <kireeti@JUNIPER.NET> Thu, 17 October 2002 20:34 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 QAA25161 for <ospf-archive@LISTS.IETF.ORG>; Thu, 17 Oct 2002 16:34:14 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0077951F@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 16:36:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307738 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 16:36:24 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 16:36:24 -0400
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9HKaOm34992 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 17 Oct 2002 13:36:24 -0700 (PDT) (envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g9HKaNR38052 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 17 Oct 2002 13:36:23 -0700 (PDT) (envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Message-ID: <20021017131430.M37850-100000@kummer.juniper.net>
Date: Thu, 17 Oct 2002 13:36:23 -0700
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Kireeti Kompella <kireeti@JUNIPER.NET>
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <3DAF1747.9060504@redback.com>
Precedence: list

Hi Acee,

On Thu, 17 Oct 2002, Acee Lindem wrote:

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

Thanks.  Someone else also pointed this out.

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

Any objections?  If not, I will make this change.

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

While this document doesn't work ideally for multipoint links with
more that 2 devices, it is used.  Also, this has been implemented
and is running code, so changing the spec to omitting this TLV at
this point would cause more problems than it would solve.

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

Instead, how about specifying explicitly in the ospf gmpls draft
that the text there applies to the base TE doc as well as the GMPLS
extensions?  Otherwise, draft-katz-yeung-traffic-08.txt will need
the graceful restart doc as a normative reference.  Note that the
TE doc has been around for many years, with interoperable
implementations etc., while graceful restart for OSPF much more recent.

BTW, can we start to progress the graceful restart (aka hitless
restart) document?  There are interoperable implementations now, and
while this doc is not as mature as TE, it certainly seems ready ....

Kireeti.