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

[Acee Lindem <[e-mail]>]

Hi Kireeti,

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.


Should a router withdraw it's TE LSA for the link if it
detects > 2 routers on a multi-access network?

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


I don't see how there could be any problems since the all zeros
address can't be of much use and section 2.4.2 says only the
Link Type and Link ID TLVs are mandatory.


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


That sounds like a great idea. I still think it should be explicitly
stated that the goal is to maintain existing traffic engineered paths while
discouraging any new ones until reservation state is obtained.


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


We're working towards that goal.

Thanks,


>
> Kireeti.
>
>


--
Acee