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

[Acee Lindem <[e-mail]>]

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.


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