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

[Tom Petch <[e-mail]>]

Before the multi-access issue is declared closed I believe there
should be an agreed definition of what multi-access means in this
context.  Because in an OSPF context ie RFC2328 (which is where I am
coming from), the term multi-access has now largely disappeared.   The
terminology is either 'Broadcast' or 'Non-Broadcast MultiAccess' and
both are defined as (p.9)

' Networks supporting many (more than two) attached routers'

So what is a two router only multi-access network?  Nothing to do with
OSPF  :-(

And this is a can of worms because RFC2328 seems not to allow a DR on
two router networks while certain manufacturers of routers do (and I
even see LSA with a DR when there is only one of those manufacturers'
routers active!).

Here, by implication, from the TLV definition in this draft,
multiaccess means a network with a DR.  And then there are other
nasties like NBMA networks which lose full connectivity and so should
stop having a DR!

Tom Petch

-----Original Message-----
From: Acee Lindem <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 22 October 2002 21:30
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt


>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