Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Fri, 9 Aug 2002 08:26:58 -0400

Hi Peter,

> We use Opaque LSAs to transport some application specific information,
> where OSPF is purely a transport mechanism. My feeling is that we should
> not use OSPF to keep track of the reachability of the Opaque LSA source.
> It's the application that should take care of the cases where the source
> becomes unreachable.

The contents of the Opaque LSA's are still transparent to us i.e. we do not
look at the information carried by the opaque LSA. We only check the opaque
type, which has to be done for all other kinds of Opaque LSA's too(as not
all opaque LSA's are sent to external applications), and check the existence
of the originator in case its a PCSD, which can be done with no change to
the base protocol at all.

I am wondering why we would not like to use a mechanism in the transport
when it can be easily done there and burden the application? One reason I
could come across was it probably cannot be done the same way in ISIS(though
I haven't read the ISIS draft)

However I do agree it is not so much of an issue at all, even if its not
advertized as ASBR's and left as is in the draft(just some extra lag time on
retries and choosing a different PCS in case of failure to get a response).

We have had a fairly comprehensive and fruitful discussion on the topic
already and I guess, we all know the merits and demerits, so it is more of a
question of the tradeoffs, either ways.

Thanks,
Vishwas

---

From: Acee Lindem <[email-masked]>
Date: Fri, 9 Aug 2002 10:39:22 -0400

Vishwas, Peter, Venkata,

Here is my take:

If it is acceptable for the Path-Comp-Clients
to retry until they find a reachable and operational
Path-Comp-Server from the alternatives then this is
probably the best option. This keeps the selection of the
Path-Comp-Server entirely within the path computation
application.

If this isn't operationally acceptable, then I'd vote for
the Path-Comp-Server setting its E bit and having OSPF
in the Path-Comp-Clients prune the list of Path-Comp-Servers
to those that are reachable. While this is a bit of a hack
it has it benefits (as discussed previously) and may be
applicable to future opaque LSA applications.

My least favorite alternative is allowing the setting of the
E bit to be optional since it requires implementation of the
Path-Comp-Server reachability checking in both OSPF and the
the Path-Comp-Clients.

Thanks,
Acee

--
Acee