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

[Acee Lindem <[e-mail]>]

Tom,

Kireeti can keep this on his list of editorial comments to
apply prior to publication. This document has been
around for years and has been through last call for both
the TE and OSPF WGs. Hence, I think the best way to handle
it would be with a single statement defining multi-access
for the context of the draft.


Tom Petch wrote:

> Comment in line.
>
> -----Original Message-----
> From: Acee Lindem <[e-mail]>
> To: [e-mail] <[e-mail]>
> Date: 25 October 2002 21:05
> Subject: Re: Comments on draft-katz-yeung-traffic-08.txt
>
>
>
>>Tom Petch wrote:
>>
>>
>>>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)
>>>
>>
>>Hi Tom,
>>
>>Muli-access encompasses both these types.
>>
>
>
> Then say so!  To quote RFC2178
>
> 'References to "multi-access" networks have been deleted'
>
> ie OSPF abandoned the term multi-access in July 1997 so if you are
> going to re-introduce it in 2002, you need to define it so that when
> this RFC-to-be is read by people (unlike like you and me) whose
> experience does not span the previous decade, they are clear what you
> mean.
>
>
>>
>>>' 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!).
>>>
>>
>>Assuming the routers are eligible (priority != 0), RFC 2328 does
>>specify  DR (and BDR) election on a 2 router broadcast or NBMA
>>
> network.
>
>>In fact, a router will become a DR on a 1 router network - it just
>>won't originate a network LSA.
>>
>>
>>
>>>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
>>>>
>>>>
>>
>>--
>>Acee
>>
>


--
Acee