All,
See inline
On 07/31/2011 06:43 PM, JP Vasseur wrote:
**
draft-lu-ospf-area-tlv-01.txt
Wenhu: *Good reception.* Why do we need to know Area ID? Isn't it
enough to
simply know if ABR is TE enabled? Solution avoids "brute force"
solution and
produces faster convergence.
As detailed below, I tend to think there is a use case to be able to
dynamically map "TE enabled ABRs" and the domains (areas) they belong to.
Abhay: Discussed with PCE chairs. RFC 5088 - extensions for PCE. Look
at those
extensions to see if they can be used.
After a quick read, I think both are somehow orthogonal /complementary.
RFC 5088 is a means for a PCE to announce its capabilities, extending
the Router Information LSA [RFC 4970] with another TLV. I wouldn't
extend the "PCE Discovery" as in RFC 5088 but 4970 itself :
a) For PCED typically, the "source" of the information would be the PCE
itself (e.g. advertising router), although nothing precludes any other
LSR to act as a proxy. As such, it can announce its own domains as well
as its neighboring domains (covering both areas and AS). Still, unless I
am mistaken, this only identifies the domain, not the exit border nodes
that leads to those domains. The mapping ABRs <-> neighboring domains is
missing, is it?
b) conceptually, it covers the PCE, not the nodes / ABRs themselves.
Capabilities of ABRs should be decoupled from those of the PCE.
However, as I mentioned in a previous mail to pce@, it may make sense to
use extensions similar to those in RFC4970. As stated within: The
Router Informational Capabilities TLV MAY be followed by optional TLVs
that further specify a capability. Similar to the OSPF Traffic
Engineering support [TE] bit, there could be a TLV that lists the areas
the ABR is connected to, which is pretty much what the draft-lu-ospf covers
Finally: I would *strongly* :-) suggest to change draft section 5.2. TLV
encoding
- align to OSPF-TE TLV defintion: uint16_t for type uint16_t for length
(value part, padding not included)
- list areas keeping uint32_t alignment in the "struct".
JP> The draft was discussed in the PCE WG meeting, but there was no
consensus that
this document provides an extension that addresses a use case for
PCE. To be discussed
on the PCE mailing list and we will keep you posted.
For what is worth, I do believe that dynamic discovery of (generic)
domain border nodes and their corresponding neighbouring domains and
reachable endpoints is a use case that enables multi-domain path
computation with less configuration. Current mechanisms can somehow made
to work, but may be improved (in this particular case, knowing the Areas
an ABR is connected to. the PCE could generate the PCE discovery
including the neighboring domains TLV after processing the Areas the
ABRs are attached to).
Thanks for reading
Ramon
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
