[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

[ post by non-subscriber.  with the massive amount of spam, it is easy to
 miss and therefore delete mis-posts.  so fix subscription addresses! ]

Kireeti,

Can we close on the remaining issues?

  1. With respect to the Remote Interface IP Addres TLV, is
     there really any reason to include it with a value of 0.0.0.0
     for a multi-access link? I can't see how there could be
     a compatibility issue since the rough count on the list
     revealed more implementations that omitted the TLV
     altogether.

  2. With respect to more than two routers on a multi-access
     network, it seems there is considerable support for
     allowing this even though it is not fully specified.
     Could you add something along these lines to the second
     paragraph of the limitations section:

     "Operation over multiaccess links with more than two
      devices is not specifically prohibited. TE operation
      and the use of reservation state is a matter for
      further study".


Thanks,
Acee




Kireeti Kompella wrote:


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.




--
Acee