Subject: [Pce] Fwd: [OSPF] IETF 81 WG Minutes

From: JP Vasseur <[email-masked]>
Date: Sun, 31 Jul 2011 12:43:18 -0400

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Subject: Re: [OSPF] IETF 81 WG Minutes
> Date: July 31, 2011 12:13:02 PM EDT
> To: Acee Lindem <[email-masked]>, "Abhay Roy (akr)" <[email-masked]>
> Cc: OSPF List <[email-masked]>
> 
> Thanks Acee,
> 
> Just a feed-back on one ID after the PCE WG meeting:
> 
> 
> 8) Updates to OSPF TE Extension for Area IDs    Slides
>    draft-lu-ospf-area-tlv-01.txt
> - Wenhu Lu 
> 10 minutes
> 
> See slides
> 
> Abhay: What were comments in PCE presentation?
> 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.
> 
> Abhay: Discussed with PCE chairs. RFC 5088 - extensions for PCE. Look at those 
> extensions to see if they can be used.
> Wenhu: Will do that.
> 
> 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.
> 
> Thanks.
> 
> JP.
> 
> On Jul 29, 2011, at 9:30 PM, Acee Lindem wrote:
> 
>> I've posted the IETF WG Minutes. Thanks much to Les Ginsberg for taking them. There was one ISP representative from Asia who commented but we did not get his name. If this was you, please unicast me and I will update the minutes with your name.  
>> 
>> Abhay and I will follow up with E-mails on specific documents presented at IETF 81. 
>> 
>> http://www.ietf.org/proceedings/81/minutes/ospf.txt
>> 
>> Thanks,
>> Acee 
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 01 Aug 2011 02:10:04 +0200

All,

See inline

On 07/31/2011 06:43 PM, JP Vasseur wrote:
> **

>> Wenhu: *Good reception.* Why do we need to know Area ID? Isn't it 
>> enough to
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.

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

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

---

From: JP Vasseur <[email-masked]>
Date: Mon, 1 Aug 2011 00:16:07 -0400

Hi Ramon,

On Jul 31, 2011, at 8:10 PM, Ramon Casellas wrote:

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

> 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) 
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Mon, 1 Aug 2011 00:16:25 -0400

Hi Ramon,

Thanks.