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

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 7 Aug 2002 07:52:06 -0400

Hi Folks,

Peter Psenak and I have been discussing the following and we would like your
views.

The PCS/some machine in the OSPF domain advertizes the capabilities of the
PCS so that other routers can dynamically learn about the existance of the
PCS. If the PCS looses its "path computation" capability the PCSD LSA is
flushed to indicate that. However when the PCS goes down/is
disconnected/partitioned from the domain any other router in the domain
cannot directly know of the fact.

To get over this, one of the suggestions is to advertize the PCS/the router
advertizing the PCS capability to the domain as an ASBR. All routers in the
domain would know of the PCS/the router if there was a router route to the
PCS. As soon as the PCS goes down the router route to it is removed, and
hence we can easily find out the existance of a PCS.

Another way to do it could be to see if there is a route to the PCS on the
router. However because of the fact that a PCS could be well in another
domain/another area, and the prefixes are aggregated, there would be no way
to know for certain if the PCS is up or not for certain.

We would want to know views on the above or any other method to dynamically
learn of the existence of the PCS.

Thanks,
Vishwas

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 7 Aug 2002 21:28:44 +0200

Vishwas,
   I think you forgot to include third option - that PCS always originates
only Type-10 LSA and ABRs 'translate' it between areas. ABR knows intra-area
reachability of originator and can withdraw self-originated translated
copies, if needed.
   Obvious minuses of this approach are:
- Overall increased complexity of the specification and implementation,
though I can't say that this increase is dramatic. This is the most serious
minus, IMO.
- At least one ABR to each area-PCSuser must support this specification.
Doesn't look like _really_ problematic issue, though also not very nice.
- Receiving router may get more than one instance of same information. Can
be easily identified as such, if needed. For example, by requiring TLV with
originator RID
- Increased load on ABRs and increased number of LSAs in areas. Not an issue
at all, as we are talking about a few LSAs only.

I think this option at least deserves to be mentioned.

Anton

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Aug 2002 01:06:33 -0400

Vishwas,

I like the idea of a PCS simply setting the E bit
in its router LSA(s) and using the reachability of
the PCS's router route to determine whether it is
available. My reasons:

1. It is completely backward compatible. All OSPF routers
    in the routing domain will support this mechanism without
    update.

2. There really shouldn't be that many of these beasts in
    a routing domain. Hence, the impact of a few extra
    router routes or type 4 summary LSAs should be negligible.

3. It is consistent with the "spirit" of the opaque LSAs. Routers
    that don't support the path computation application won't be
    impacted.

Thanks,
Acee

--
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 8 Aug 2002 10:49:51 +0200

> to know for certain if the PCS is up or not for certain.

just for clarification, current draft does not propose any method of
maintaining the reachability of the PCS servers on the routers and
relies purely on the IP reachability of the 'PCS address' that is
advertised in the Opaque LSA. If the PCS address can not be reached (no
reply to the Path computation Request), PCS client may try to contact an
alternative PCS server.

thanks,
Peter