Hi Ramon, On Jul 31, 2011, at 8:10 PM, Ramon Casellas wrote:
> 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. Let's discuss this aspect. It was explained that there was a need to know that a router was TE-enabled to avoid a signaling failure … how is that different from other parameters ? Second question is what can you do with the OSPF area ID ? I cannot see any reason for knowing the area ID an ABR is connected to for inter-area TE LSP computation ? Thanks. JP. > >>> 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
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
