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

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 8 Aug 2002 00:19:27 -0400

Hi Anton,

You are right, and we did think of this approach, more from the NSSA and
Stub point of view, because in those areas type-11 LSA's are not flooded.

However we did not want to have any translation function on stub/NSSA ABRs.
Stub areas should remain stub (no external info should be sent inside).
These
areas should have their own PCS inside the area if needed, or clients inside
stub/NSSA areas should be configured statically with the PCS address, to
avoid added complexity.

Thanks,
Vishwas

-----Original Message-----
From: Anton Smirnov [mailto:[email-masked]]
Sent: Thursday, August 08, 2002 12:59 AM
To: [email-masked]
Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt

   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

----- Original Message -----
From: "Manral, Vishwas" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 07, 2002 1:52 PM
Subject: [OSPF] draft-vasseur-mpls-ospf-pcsd-discovery-00.txt

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