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

[Tom Petch <[e-mail]>]

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