Subject: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

From: Wenhu Lu <[email-masked]>
Date: Wed, 13 Jul 2011 21:15:34 -0400

Dear all, 

A new version of I-D, draft-lu-ospf-area-tlv-01.txt has been successfully submitted by Wenhu Lu and posted to the IETF repository. http://tools.ietf.org/html/draft-lu-ospf-area-tlv-01

There's quite a bit of updates over the 00 version, mainly on the clarifications, motivations, and use-cases, thanks to all that provided comments and inputs.

I'll be grateful for your further review and comments before the upcoming IETF when I plan to use the PCE slot to address the concerns and issues.

Regards,
-wenhu

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 14 Jul 2011 09:45:47 +0530

Dear Wenhu and WG, 

I wanted to mention here in WG about the idea presented in IETF-78 in
Maastricht.  

OSPF Protocol Extensions for Boundary Node Discovery (BND)

http://datatracker.ietf.org/doc/draft-dhody-pce-bn-discovery-ospf/

During the meeting WG can evaluate if any collaboration and/or consensus be
reached in this area. 

Thanks & Regards,

Dhruv

****************************************************************************
***********

Dhruv Dhody, Senior Tecnical Leader, Huawei Tecnologies, Bangalore, India,
Ph. +91-9845062422

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wenhu
Lu
Sent: Thursday, July 14, 2011 6:46 AM
To: [email-masked]
Subject: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Dear all, 

A new version of I-D, draft-lu-ospf-area-tlv-01.txt has been successfully
submitted by Wenhu Lu and posted to the IETF repository.
http://tools.ietf.org/html/draft-lu-ospf-area-tlv-01

There's quite a bit of updates over the 00 version, mainly on the
clarifications, motivations, and use-cases, thanks to all that provided
comments and inputs.

I'll be grateful for your further review and comments before the upcoming
IETF when I plan to use the PCE slot to address the concerns and issues.

Regards,

-wenhu

_______________________________________________

Pce mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Thu, 14 Jul 2011 12:19:30 +0200

Hi Dhruv,

On Jul 14, 2011, at 6:15 AM, Dhruv Dhody wrote:

> Dear Wenhu and WG,
>  
> I wanted to mention here in WG about the idea presented in IETF-78 in Maastricht.  
>  
> During the meeting WG can evaluate if any collaboration and/or consensus be reached in this area.

Would you want to share with the WG how you see the positioning of these two ID ?

Thanks.

JP.

>  
> Thanks & Regards,
> Dhruv
>  
> ***************************************************************************************
> Dhruv Dhody, Senior Tecnical Leader, Huawei Tecnologies, Bangalore, India, Ph. +91-9845062422
>  
> This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Wenhu Lu

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 15 Jul 2011 10:19:29 +0530

Hi, 

BN Discovery draft was kept generic for the purpose of ease and
extensibility. 

I see further growth in this ID as the work on PCE-VPN and PCE-INTER-LAYER
advances. 

As a WG, we need consensus on the Motivation and Need for this kind of work.

Then we can discuss on the way we achieve this via area-tlv in OSPF-TE or a
generic Boundary Node Discovery. 

Regards,

Dhruv

Note: the obvious difference between the IDs

1. draft-lu focuses on ABRs with TE property for PCEs to compute LSPs.
draft-dhody focuses on the discovery of both ABRs/ASBRs.

2. draft-lu's area TLV is part of ospf TE extension. draft-dhody's (Boundary
Node Discovery) BND TLV is generic.

  _____  

From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, July 14, 2011 3:50 PM
To: Dhruv Dhody
Cc: 'Wenhu Lu'; [email-masked]
Subject: Re: [Pce] New Version Notification for
draft-lu-ospf-area-tlv-01.txt

Hi Dhruv,

Dear Wenhu and WG, 

Would you want to share with the WG how you see the positioning of these two
ID ?

Thanks.

JP.

Thanks & Regards,

Dhruv

-----Original Message-----

Dear all, 

Regards,

-wenhu

Pce mailing list

[email-masked]

---

From: Wenhu Lu <[email-masked]>
Date: Tue, 19 Jul 2011 17:32:33 -0400

Thanks Dhruv for the summary.
At least the authors of the two drafts have the same vision that advertising OSPF area IDs will help PCE's multi-area path computation, so that operators do not have to configure manually the list of boundary routers.
PCEers, please voice your opinions whether it's a good idea to automate the discovery of the OSPF area IDs.

If we agree that automating the ABR provisioning is a good thing, please be advised that the rationale and approaches of the two drafts are quite different.

draft-lu-ospf-area-tlv focuses on one thing, i.e. to enable CSPF to do multi-area path computation with no need of manual ABR provisioning. Here're several key points (please refer to the draft for detail):
1. An OSPF Area-ID-TLV is introduced. This TLV tells whether and how CSPF can extend its LSP computation to across area boundaries.
2. The originating point is OSPF's TE function. The TLV is kept under OSPF TE extensions (like router-address TLV and link TLV). This is to ensure that the ABR is an LSR capable of transit TE traffic. This is important because an ABR is not necessary an LSR.
3. From CSPF point-of-view, if the area-id info is readily available in TED, CSPF's job will be easy (please see use-cases 1 and 2). It doesn't need to talk to OSPF or other network components to acquire ABR information. The change to CSPF is minimal.
4. It addresses only multi-area path computation. It does not address multi-AS path computation.

draft-dhody-pce-bn-discovery-ospf is not tied with TE but kept generic (some use-cases would be helpful). It focuses on both multi-area and multi-AS. I believe the topic is also important.

Thanks,
-wenhu

________________________________
From: Dhruv Dhody [mailto:[email-masked]]
Sent: Thursday, July 14, 2011 9:49 PM
To: 'JP Vasseur'
Cc: Wenhu Lu; [email-masked]
Subject: RE: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Hi,

BN Discovery draft was kept generic for the purpose of ease and extensibility.
I see further growth in this ID as the work on PCE-VPN and PCE-INTER-LAYER advances.

As a WG, we need consensus on the Motivation and Need for this kind of work.
Then we can discuss on the way we achieve this via area-tlv in OSPF-TE or a generic Boundary Node Discovery.

Regards,
Dhruv

Note: the obvious difference between the IDs
1. draft-lu focuses on ABRs with TE property for PCEs to compute LSPs.  draft-dhody focuses on the discovery of both ABRs/ASBRs.
2. draft-lu's area TLV is part of ospf TE extension. draft-dhody's (Boundary Node Discovery) BND TLV is generic.

***************************************************************************************
Dhruv Dhody, Senior Tecnical Leader, Huawei Tecnologies, Bangalore, India, Ph. +91-9845062422
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
________________________________
From: JP Vasseur [mailto:[email-masked]]
Sent: Thursday, July 14, 2011 3:50 PM
To: Dhruv Dhody
Cc: 'Wenhu Lu'; [email-masked]
Subject: Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Hi Dhruv,

Dear Wenhu and WG,

Thanks.

JP.

Thanks & Regards,

Dhruv

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Wenhu Lu
Sent: Thursday, July 14, 2011 6:46 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Dear all,

Regards,

-wenhu

Pce mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 20 Jul 2011 09:09:50 +0200

Dear PCERs,

Please see inline for my 2 cents...

El 19/07/2011 23:32, Wenhu Lu escribió:
> At least the authors of the two drafts have the same vision that 
> advertising OSPF area IDs will help PCE's multi-area path computation, 
> so that operators do not have to configure manually the list of 
> boundary routers.

To put it shortly, I agree that dynamic discovery of border nodes for 
the deployment of PCE based multi-domain path computation is desirable.

To date, we rely on either static provisioning, or dynamic parsing of 
external / summary LSAs, identifying advertising routers as either ABRs 
or ASBRs. I browsed both drafts and I tend to agree that one of the main 
drawbacks of this approach is that the control plane addressing, etc and 
the TED are not clearly separated, relying of router address TLVs to map 
the advertising router; other details are given in 
draft-lu-ospf-area-tlv-01 Section 3.2.

However, I foresee that the same questions can arise, later on, 
regarding reachability of endpoints located in other TED domains. If one 
wants to decouple ABRs as advertised within OSPFv2 LSDB and TE border 
nodes, would it be reasonable that external / summaries be decoupled too?

> PCEers, please voice your opinions whether it's a good idea to 
> automate the discovery of the OSPF area IDs.

As stated, a mechanism by which a PCE is able to know in which area(s) 
is located, and border nodes is desirable. I guess my main comment is a 
question; would it be appropriate to generalize this e.g. to Areas and 
AS? I do not object to having one draft for the ABR / OSPF-TE case, but 
when possible, I would like the PCE architecture to apply to 
multi-domain in general, to have a unified approach, both for the 
multi-AS (i.e. with inter-domain links) and multi-Area (i.e. with ABRs) 
and to treat "TE domains" generically. In other words, how can we 
"extend" a TED with automated information enabling multi-domain path 
computation - topology and reachability-, generically, while mantaining 
a clear separation of control plane and TED.

> If we agree that automating the ABR provisioning is a good thing, 
> please be advised that the rationale and approaches of the two drafts 
> are quite different.
> draft-lu-ospf-area-tlv focuses on one thing, i.e. to enable CSPF to do 
> multi-area path computation with no need of manual ABR provisioning. 
> Here're several key points (please refer to the draft for detail):
> 1. An OSPF Area-ID-TLV is introduced. This TLV tells whether and how 
> CSPF can extend its LSP computation to across area boundaries.

I still have doubts regarding wheter this needs to be a top TLV (draft 
mentions RFC3630 section 2.4). What would be the relation with e.g. RFC4970?

> 2. The originating point is OSPF's TE function. The TLV is kept under 
> OSPF TE extensions (like router-address TLV and link TLV). This is to 
> ensure that the ABR is an LSR capable of transit TE traffic. This is 
> important because an ABR is not necessary an LSR.
> 3. >From CSPF point-of-view, if the area-id info is readily available 
> in TED, CSPF's job will be easy (please see use-cases 1 and 2). It 
> doesn't need to talk to OSPF or other network components to acquire 
> ABR information. The change to CSPF is minimal.
Understood.

> draft-dhody-pce-bn-discovery-ospf is not tied with TE but kept 
> generic (some use-cases would be helpful). It focuses on both 
> multi-area and multi-AS. I believe the topic is also important.
>
Agreed

Thanks and best regards

Ramon

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 20 Jul 2011 15:02:38 +0530

Hi Wenhu & WG, 

I wanted to mention following points with respect to this discussion:

(1)     I feel its better to keep the scope of CSPF algorithm limited to
single area. In case PCE functionality resides at ABR router which has
visibility into multiple areas, it better to apply BRPC as before and the
same PCE can compute VSPT(i) and then VSPT(i-1) . I am not in favor of CSPF
doing inter-area path computation by combining TED of both areas. 

(2)    In case of ABR is not an LSR: Based on local policy BN may choose not
to advertise the BN Discovery TLV [draft-dhody-pce-bn-discovery-ospf], also
if PCE discovers the BN, it can easily choose to ignore it if that node is
not in the TED.  

Regards,

Dhruv

****************************************************************************
***********
Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India,
Ph. +91-9845062422

  _____  

From: Wenhu Lu [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2011 3:03 AM
To: Dhruv Dhody; 'JP Vasseur'
Cc: [email-masked]
Subject: RE: [Pce] New Version Notification for
draft-lu-ospf-area-tlv-01.txt

At least the authors of the two drafts have the same vision that advertising
OSPF area IDs will help PCE's multi-area path computation, so that operators
do not have to configure manually the list of boundary routers.

PCEers, please voice your opinions whether it's a good idea to automate the
discovery of the OSPF area IDs.

If we agree that automating the ABR provisioning is a good thing, please be
advised that the rationale and approaches of the two drafts are quite
different. 

draft-lu-ospf-area-tlv focuses on one thing, i.e. to enable CSPF to do
multi-area path computation with no need of manual ABR provisioning. Here're
several key points (please refer to the draft for detail):

1. An OSPF Area-ID-TLV is introduced. This TLV tells whether and how CSPF
can extend its LSP computation to across area boundaries.

2. The originating point is OSPF's TE function. The TLV is kept under OSPF
TE extensions (like router-address TLV and link TLV). This is to ensure that
the ABR is an LSR capable of transit TE traffic. This is important because
an ABR is not necessary an LSR.

3. From CSPF point-of-view, if the area-id info is readily available in TED,
CSPF's job will be easy (please see use-cases 1 and 2). It doesn't need to
talk to OSPF or other network components to acquire ABR information. The
change to CSPF is minimal.

4. It addresses only multi-area path computation. It does not address
multi-AS path computation.

draft-dhody-pce-bn-discovery-ospf is not tied with TE but kept generic (some
use-cases would be helpful). It focuses on both multi-area and multi-AS. I
believe the topic is also important.

Thanks,

-wenhu

  _____  

Subject: RE: [Pce] New Version Notification for

Hi, 

Regards,

Dhruv

  _____  

Hi Dhruv,

Dear Wenhu and WG, 

Thanks.

JP.

Thanks & Regards,

Dhruv

-----Original Message-----

Dear all, 

Regards,

-wenhu

Pce mailing list

[email-masked]

---

From: Wenhu Lu <[email-masked]>
Date: Wed, 20 Jul 2011 19:06:22 -0400

Hi Ramon,
Thank you for your review and sharing. Please see my comments inline [wenhu].

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: Wednesday, July 20, 2011 12:10 AM
To: [email-masked]
Subject: Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Dear PCERs,

To put it shortly, I agree that dynamic discovery of border nodes for the deployment of PCE based multi-domain path computation is desirable.

To date, we rely on either static provisioning, or dynamic parsing of external / summary LSAs, identifying advertising routers as either ABRs or ASBRs. I browsed both drafts and I tend to agree that one of the main drawbacks of this approach is that the control plane addressing, etc and the TED are not clearly separated, relying of router address TLVs to map the advertising router; other details are given in draft-lu-ospf-area-tlv-01 Section 3.2.
[wenhu] Curiously which component is doing the parsing?
            If it's CSPF, there will be quite bit of work.
            Or if it's OSPF, how is the result passed to CSPF?

 However, I foresee that the same questions can arise, later on, regarding reachability of endpoints located in other TED domains. If one wants to decouple ABRs as advertised within OSPFv2 LSDB and TE border nodes, would it be reasonable that external / summaries be decoupled too?
 [wenhu] I couldn't agree with you more on this. And IMHO the complete way of decoupling is not to use external (or summaries) routes for TE purpose. The external routes may or may not be qualified for TE reachability. Further the external routes may be multi-homed.
But how can we do multi-AS path computation if we don't use the external routes ? This is an interesting topic. We can discuss this offline if you wish.
PCEers, please voice your opinions whether it's a good idea to automate the discovery of the OSPF area IDs.

As stated, a mechanism by which a PCE is able to know in which area(s) is located, and border nodes is desirable. I guess my main comment is a question; would it be appropriate to generalize this e.g. to Areas and AS? I do not object to having one draft for the ABR / OSPF-TE case, but when possible, I would like the PCE architecture to apply to multi-domain in general, to have a unified approach, both for the multi-AS (i.e. with inter-domain links) and multi-Area (i.e. with ABRs) and to treat "TE domains" generically. In other words, how can we "extend" a TED with automated information enabling multi-domain path computation - topology and reachability-, generically, while mantaining a clear separation of control plane and TED.
[wenhu] I'm with you. A unified approach would be ideal. But it may not be easy to find one shoe that fits all.
If we agree that automating the ABR provisioning is a good thing, please be advised that the rationale and approaches of the two drafts are quite different.

I still have doubts regarding wheter this needs to be a top TLV (draft mentions RFC3630 section 2.4). What would be the relation with e.g. RFC4970?
[wenhu] I received some suggestions to place this TLV to under rtr-address-tlv. I'm open to this part.
            RFC4970 is big umbrella that covers all (OSPF router capabilities). It may serve well to the multi-domain case. For multi-area purpose I think the proposed ospf area tlv offers a simple and feasible solution.

Regards,
-wenhu

2. The originating point is OSPF's TE function. The TLV is kept under OSPF TE extensions (like router-address TLV and link TLV). This is to ensure that the ABR is an LSR capable of transit TE traffic. This is important because an ABR is not necessary an LSR.
3. >From CSPF point-of-view, if the area-id info is readily available in TED, CSPF's job will be easy (please see use-cases 1 and 2). It doesn't need to talk to OSPF or other network components to acquire ABR information. The change to CSPF is minimal.
4. It addresses only multi-area path computation. It does not address multi-AS path computation.
Understood.

Agreed

Thanks and best regards

Ramon

---

From: Wenhu Lu <[email-masked]>
Date: Wed, 20 Jul 2011 19:32:33 -0400

Hi Dhruv,
Please see my comments inline.

________________________________
From: Dhruv Dhody [mailto:[email-masked]]
Sent: Wednesday, July 20, 2011 2:33 AM
To: Wenhu Lu; 'JP Vasseur'
Cc: [email-masked]
Subject: RE: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Hi Wenhu & WG,

(1)     I feel its better to keep the scope of CSPF algorithm limited to single area. In case PCE functionality resides at ABR router which has visibility into multiple areas, it better to apply BRPC as before and the same PCE can compute VSPT(i) and then VSPT(i-1) . I am not in favor of CSPF doing inter-area path computation by combining TED of both areas.
[wenhu] I guess you were referring to section 6. In that section I listed a number of known methods and how the proposed TLV can benefit them. I didn't endorse one method over the other. Whether to use crankback or BRPC, etc is upto the network planners and operators.
      I generally am against the global TED for the obvious reasons like scalability. However if a PCE happens to sit on an area border and thus possesses multiple TEDs, this is different from the glbal TED concept and I don't view this as a bad thing. It's perfectly fine if someone wants to take advantage of this.

(2)    In case of ABR is not an LSR: Based on local policy BN may choose not to advertise the BN Discovery TLV [draft-dhody-pce-bn-discovery-ospf], also if PCE discovers the BN, it can easily choose to ignore it if that node is not in the TED.
[wenhu] I don't know how the local policy would look like. But I'm afraid that configuring local policy is literally manual provisioning which defeats the purpose of dynamic ABR discovery. Maybe ignoring is easier.

Regards,
-wenhu

Regards,
Dhruv

Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422

Thanks,
-wenhu

Regards,
Dhruv

Hi Dhruv,

Dear Wenhu and WG,

Thanks.

JP.

Thanks & Regards,

Dhruv

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Wenhu Lu
Sent: Thursday, July 14, 2011 6:46 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Dear all,

Regards,

-wenhu

Pce mailing list

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 21 Jul 2011 13:50:12 +0200

Wenhu, PCErs

further comments tagged [Ramon]

El 21/07/2011 1:06, Wenhu Lu escribió:
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Ramon Casellas
> *Subject:* Re: [Pce] New Version Notification for 
> external / summary LSAs, identifying advertising routers as either 
> ABRs or ASBRs. I browsed both drafts and I tend to agree that one of 
> the main drawbacks of this approach is that the control plane 
> addressing, etc and the TED are not clearly separated, relying of 
> router address TLVs to map the advertising router; other details are 
> given in draft-lu-ospf-area-tlv-01 Section 3.2.
[Ramon] I'm not sure we are doing something terribly complicated or hard 
:) in its simplest form, the PCE carries out stateful inspection of 
OSPF-TE packets that it can "capture" (sent by other entities, sniffing 
the network, via process API, or as an OSPF-TE listener,  it's quite 
open actually), in order to construct an in memory directed graph  (TED) 
on top of which perform computation.  From the PCE perspective, OSPF-TE 
is just one of many ways to get the TED. Basically it proceeds by 
parsing the Link State Update packets (discarding the rest), and the 
LSAs found within. At the beginning (Single domain) we only parsed e.g. 
area / opaque LSAs, but when we started with multi-domain, we started 
parsing summary LSAs, ASBR summary LSAs and AS external LSAs. For 
summary LSAs, the prefixes announcing "reachability" are parsed with 
their metrics etc. getting the masks from within the summaries. 
Consequently, from within the PCE, the advertising router is then marked 
as a "border node" (ABR or ASBR depending on the LSA type). The PCE kees 
thus information on border nodes and reachability, used in BRPC and H-PCE-

As you may guess, some issues arise, solved mainly by the congruent 
topology, the 1:1 relationship between GMPLS controller and data plane 
node and the fact that we use a single address for advertising router 
that corresponds to the Router Address TLVs (ROuter ID, Node Id or 
similar names). Otherwise, we are considering latest Andy Malis RFC on 
ASON routing.

> regarding reachability of endpoints located in other TED domains. If 
> one wants to decouple ABRs as advertised within OSPFv2 LSDB and TE 
> border nodes, would it be reasonable that external / summaries be 
> decoupled too?
>  [wenhu] I couldn't agree with you more on this. And IMHO the complete 
> way of decoupling is not to use external (or summaries) routes for TE 
> purpose. The external routes may or may not be qualified for TE 
> reachability. Further the external routes may be multi-homed.
> But how can we do multi-AS path computation if we don't use the 
> external routes ? This is an interesting topic. We can discuss this 
> offline if you wish.
[Ramon] I'm open to this, it may be a new point for a future re-charter, 
but I'm not sure the scope / WG. It has of course strong links with ASON 
routing and CCAMP. I fully agree that to enable multi-domain path 
computation amongst collaborating PCEs, we need to decouple control 
plane and data plane, where the TED refers to the later. Although the 
scope of Path Computation seems naturally fitted to a single TE domain, 
collaborating mechanisms require somehow "extending" this TED with exit 
/ entry points and the relationship with other (at least neighboring 
domains) and doing this by virtue of mapping with control plane 
identifiers or OSPFv2/BGP reachability may be improved?

> is located, and border nodes is desirable. I guess my main comment is 
> a question; would it be appropriate to generalize this e.g. to Areas 
> and AS? I do not object to having one draft for the ABR / OSPF-TE 
> case, but when possible, I would like the PCE architecture to apply to 
> multi-AS (i.e. with inter-domain links) and multi-Area (i.e. with 
> ABRs) and to treat "TE domains" generically. In other words, how can 
> we "extend" a TED with automated information enabling multi-domain 
> path computation - topology and reachability-, generically, while 
> mantaining a clear separation of control plane and TED.
> [wenhu] I'm with you. A unified approach would be ideal. But it may 
> not be easy to find one shoe that fits all.

[Ramon]The multi-area context ba be a good start
>>
>> I still have doubts regarding wheter this needs to be a top TLV 
>> (draft mentions RFC3630 section 2.4). What would be the relation with 
>> e.g. RFC4970?
>            RFC4970 is big umbrella that covers all (OSPF router 
> capabilities). It may serve well to the multi-domain case. For 
> multi-area purpose I think the proposed ospf area tlv offers a simple 
> and feasible solution.
[Ramon] No strong opinions, I guess we just need to identify 
possibilities and get a consensus on the actual encoding

Thanks and best regards

Ramon

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01

---

From: Wenhu Lu <[email-masked]>
Date: Thu, 21 Jul 2011 21:13:25 -0400

Thanks Ramon for the sharing.
Regards,
-wenhu

________________________________
From: Ramon Casellas [mailto:[email-masked]]
Sent: Thursday, July 21, 2011 4:50 AM
To: Wenhu Lu
Cc: [email-masked]
Subject: Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

Wenhu, PCErs

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ramon Casellas
Subject: Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

[Ramon] I'm not sure we are doing something terribly complicated or hard :) in its simplest form, the PCE carries out stateful inspection of OSPF-TE packets that it can "capture" (sent by other entities, sniffing the network, via process API, or as an OSPF-TE listener,  it's quite open actually), in order to construct an in memory directed graph  (TED) on top of which perform computation.  From the PCE perspective, OSPF-TE is just one of many ways to get the TED. Basically it proceeds by parsing the Link State Update packets (discarding the rest), and the LSAs found within. At the beginning (Single domain) we only parsed e.g. area / opaque LSAs, but when we started with multi-domain, we started parsing summary LSAs, ASBR summary LSAs and AS external LSAs. For summary LSAs, the prefixes announcing "reachability" are parsed with their metrics etc. getting the masks from within the summaries. Consequently, from within the PCE, the advertising router is then marked as a "border node" (ABR or ASBR depending on the LSA type). The PCE kees thus information on border nodes and reachability, used in BRPC and H-PCE-

As you may guess, some issues arise, solved mainly by the congruent topology, the 1:1 relationship between GMPLS controller and data plane node and the fact that we use a single address for advertising router that corresponds to the Router Address TLVs (ROuter ID, Node Id or similar names). Otherwise, we are considering latest Andy Malis RFC on ASON routing.

 However, I foresee that the same questions can arise, later on, regarding reachability of endpoints located in other TED domains. If one wants to decouple ABRs as advertised within OSPFv2 LSDB and TE border nodes, would it be reasonable that external / summaries be decoupled too?
 [wenhu] I couldn't agree with you more on this. And IMHO the complete way of decoupling is not to use external (or summaries) routes for TE purpose. The external routes may or may not be qualified for TE reachability. Further the external routes may be multi-homed.
But how can we do multi-AS path computation if we don't use the external routes ? This is an interesting topic. We can discuss this offline if you wish.
[Ramon] I'm open to this, it may be a new point for a future re-charter, but I'm not sure the scope / WG. It has of course strong links with ASON routing and CCAMP. I fully agree that to enable multi-domain path computation amongst collaborating PCEs, we need to decouple control plane and data plane, where the TED refers to the later. Although the scope of Path Computation seems naturally fitted to a single TE domain, collaborating mechanisms require somehow "extending" this TED with exit / entry points and the relationship with other (at least neighboring domains) and doing this by virtue of mapping with control plane identifiers or OSPFv2/BGP reachability may be improved?

I still have doubts regarding wheter this needs to be a top TLV (draft mentions RFC3630 section 2.4). What would be the relation with e.g. RFC4970?
[wenhu] I received some suggestions to place this TLV to under rtr-address-tlv. I'm open to this part.
            RFC4970 is big umbrella that covers all (OSPF router capabilities). It may serve well to the multi-domain case. For multi-area purpose I think the proposed ospf area tlv offers a simple and feasible solution.
[Ramon] No strong opinions, I guess we just need to identify possibilities and get a consensus on the actual encoding

Thanks and best regards

Ramon