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

[Don Goodspeed <[e-mail]>]

OK.  I've had more time to think about this, and I withdraw
my earlier suggestions.  Listing the DR would lead to routing
loops (between DR and BDR) and/or blackholes (where the DR is
not a TE-capable router).

I also do not suggest we withdraw the TE LSAs when there are
two or more routers on a multi-access network.  It's better to
just ignore the TE LSAs that do not have a remote IP than to
flood, withdraw, flood again, etc.

Had anyone ever suggested the concept of a TE-capable DR?
It could generate a TE version of a Network LSA listing the
TE-capable routers on a link.  TE applications would then
be able to use the link for non-bandwidth TE uses.

Let me know if this has been tried and knocked down...
-don

 --- On Fri 10/18, Acee Lindem  wrote:
From: Acee Lindem [mailto: [e-mail]]
To: [e-mail]
Date: Fri, 18 Oct 2002 00:12:09 -0400
Subject: Re: Comments on draft-katz-yeung-traffic-08.txt

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

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!