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

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

El 01/08/2011 6:16, JP Vasseur escribió:
>
> 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 ?

I'm afraid I don't understand the question, sorry :) Just in case, I did 
not mean that TE enabled bit was needed. For simplicity, assume all ABRs 
are TE enabled.

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

Thinking about it, it may not be strictly needed, although I was 
thinking on corner cases such as the following. Consider the topology 
below (paraphrasing parts of Section 1.2 RFC 3509), where  an ABR has no 
backbone  connection

                           .                .
                            .    Area 0    .
                             +--+      +--+
                           ..|R1|..  ..|R2|..
                          .  +--+  ..  +--+  .
                          .        ..        .
                          .       +--+       .
                          . Area1 |R3| Area2 .
                          .       +--+  +--+ .
                          .        ..   |R4| .
                          .       .  .  +--+ .
                           .......    .......
  Being an ABR, R3 can  only consider summary-LSAs from the backbone 
when building the routing table (according to section 16.2 of 
[RFC2328]), so it will not have any inter-area routes in its routing 
table, but only intra-area routes from both Area 1 and Area 2.  
Consequently, according to section 12.4.3, R3 will originate into Areas 
1 and 2 only summary-LSAs covering destinations in the directly attached 
areas. At the same time, router R2, as an ABR connected to the backbone, 
will inject into Area 2 summary-LSAs describing the destinations in Area 
0 (the backbone), Area 1 and other areas reachable through the 
backbone.  (...) This results in a situation where internal router R4 
(or PCE) calculates its routes to destinations in the backbone and areas 
other than Area 1 via R2.  (Rcas: although this may be addressed with a 
virtual link, as RFC3509 mentions later on)

So in our use case:

  - R4 (or PCE) may want to compute an inter-area path towards some 
endpoint at area1. It may also be requested to  follow e.g. a domain 
sequence within the IRO, listing areas 2 and 1. I would like a clean way 
to consider R2 and R3 somehow differently. I believe here that knowing 
the ABRs and the involved areas can be "a good thing" e.g. in minimizing 
OF codes such as "minimum number of domains". of ocurse, if there is no 
virtual link, I can deduce that R2 is attached to Area 0 since it is 
announcing summary LSAs for Area0 and areas other than 1 but I cannot 
rely on this.

- If PCE within Area1 does not support BRPC/VPST, PCE in Area2 could 
explicitly select P2P paths from R3, selecting those ABRs that are 
directly attached to Area1. Knowing that R2 is not directly attached to 
Area1 allows PCE within area 2 to not request the R2 path.

- Knowing the area ids of the ABRs provides a simple mechanism to 
somehow deduce a domain sequence and trigger the approporiate mechanism.

Finally, somehow unrelated but in a wider scope, I am still wondering 
whether "deducing" things directly from summary LSAs rather that from 
dedicated opaque information that clearly decouples control and data 
plane is the right thing to do. Ideally (augmented) TED info should be 
self-contained in opaques :)

Probably I am missing something, so I'd be happy to stand corrected :)

Thanks
R.

-- 
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: Mon, 1 Aug 2011 22:00:44 -0400

Hi JP and all,

Thanks everyone for the comments and discussions regarding this ID during and after the PCE session.
I agree with JP that we shouldn't make changes unless they are necessary or beneficial.
I also agree with Ramon, Dhruv and Jonathan that we shouldn't settle on manual provisioning if we can do auto-discovery, and we shouldn't settle on brute force approaches if we can do things systematically.

The discussion during the PCE WG session boiled down to the question:
    for inter-area path computation, is the "brute force" method good enough that the draft method provides little merit?

Here the "brute force" means that a PCE can use OSPF type-3 LSAs to figure out the ABRs and the reachability to the LSP tailend and do path computation accordingly, regardless whether ABRs are TE enable, or which areas the ABRs are connecting to. If an ABR is not TE capable, it will be discarded later by the next PCE. Please correct me if my interpretation is wrong.

My arguments are following (Ramon already explained a use-case of the area-id in an earlier email. Here I add to it a few more points):
1. In BRPC method, the area (domain) sequence will help accomplish the inter-area path computation. Nevertheless, knowing not the area-id, the "bruth-force" won't work with the area sequence.
2. The area-id TLV also implies ABR's TE capability.
    A typical OSPF topology is a backbone with many surrounding non-backbone areas. There can be many ABRs from the backbone's perspective.
    This means that without the ABR's TE info, the crankback method will have to spend long time to go through the list.
    This also means that the BRPC method will have to build a very fat-tree (VSPT). It cannot trim the tree by excluding the non-TE ABRs and non-related areas until the VSPT is passed to the next PCE.
    For a deployed LSP based network, the number of LSPs can be thousands. Considering the re-optimization, make-before-break, bypass and backup path computation, the scalability and computation efficiency are very important factors.
    The "brute force" apparently is not designed for such heavy computation tasks. It may quickly become the scalability bottleneck.
3. In terms of information propagation, the intra-area path computation is self-sustained. The PCE gets everything from the TED. For the inter-area path computation, the self-sustaining nature can be easily preserved with the addition of the area-id-tlv.
    In this sense, the "brute force" is not only slow, it has to resort to some "out-of-band" methods to acquire the ABR information.
4. To answer Abhay's question, RFC 5088 is for PCE auto-discovery. It is not for TE-ABR auto-discovery.  As Ramon pointed out, they are orthogonal and complimentary.

Thanks,
-wenhu

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur
Sent: Sunday, July 31, 2011 9:43 AM
To: [email-masked]
Subject: [Pce] Fwd: [OSPF] IETF 81 WG Minutes

Begin forwarded message:

From: JP Vasseur <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] IETF 81 WG Minutes
Date: July 31, 2011 12:13:02 PM EDT
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "Abhay Roy (akr)" <[email-masked]<mailto:[email-masked]>>
Cc: OSPF List <[email-masked]<mailto:[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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

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

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 02 Aug 2011 13:05:25 -0400

Dear Wenhu, JP, Ramon and All,

I just wanted to add this - 

>From RFC 5441, section 4.2: 

   Note that PCE(i) only considers the entry BNs of domain(i), i.e.,

   only the BNs that provide connectivity from domain(i-1).  In other

   words, the set BN-en(k,i) is only made of those BNs that provide

   connectivity from domain (i-1) to domain(i). 

If we want to follow RFC completely and correctly, PCE must select only
those boundary nodes that provides connectivity between the domain (i-1) and
(i), and this could only be done when PCE is aware of both the BNs and their
connecting domains to make this decision correctly.  

Regards,

Dhruv

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wenhu
Lu
Sent: Monday, August 01, 2011 10:01 PM
To: JP Vasseur; [email-masked]
Subject: Re: [Pce] Fwd: [OSPF] IETF 81 WG Minutes

Hi JP and all,

Thanks everyone for the comments and discussions regarding this ID during
and after the PCE session.

I agree with JP that we shouldn't make changes unless they are necessary or
beneficial.

I also agree with Ramon, Dhruv and Jonathan that we shouldn't settle on
manual provisioning if we can do auto-discovery, and we shouldn't settle on
brute force approaches if we can do things systematically.

    for inter-area path computation, is the "brute force" method good enough
that the draft method provides little merit?

Here the "brute force" means that a PCE can use OSPF type-3 LSAs to figure
out the ABRs and the reachability to the LSP tailend and do path computation
accordingly, regardless whether ABRs are TE enable, or which areas the ABRs
are connecting to. If an ABR is not TE capable, it will be discarded later
by the next PCE. Please correct me if my interpretation is wrong.

My arguments are following (Ramon already explained a use-case of the
area-id in an earlier email. Here I add to it a few more points):

1. In BRPC method, the area (domain) sequence will help accomplish the
inter-area path computation. Nevertheless, knowing not the area-id, the
"bruth-force" won't work with the area sequence.

    A typical OSPF topology is a backbone with many surrounding non-backbone
areas. There can be many ABRs from the backbone's perspective.

    This means that without the ABR's TE info, the crankback method will
have to spend long time to go through the list.

    This also means that the BRPC method will have to build a very fat-tree
(VSPT). It cannot trim the tree by excluding the non-TE ABRs and non-related
areas until the VSPT is passed to the next PCE.

    For a deployed LSP based network, the number of LSPs can be thousands.
Considering the re-optimization, make-before-break, bypass and backup path
computation, the scalability and computation efficiency are very important
factors.

    The "brute force" apparently is not designed for such heavy computation
tasks. It may quickly become the scalability bottleneck.

3. In terms of information propagation, the intra-area path computation is
self-sustained. The PCE gets everything from the TED. For the inter-area
path computation, the self-sustaining nature can be easily preserved with
the addition of the area-id-tlv.

    In this sense, the "brute force" is not only slow, it has to resort to
some "out-of-band" methods to acquire the ABR information.

4. To answer Abhay's question, RFC 5088 is for PCE auto-discovery. It is not
for TE-ABR auto-discovery.  As Ramon pointed out, they are orthogonal and
complimentary.

Thanks,

-wenhu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: Sunday, July 31, 2011 9:43 AM
To: [email-masked]
Subject: [Pce] Fwd: [OSPF] IETF 81 WG Minutes

Begin forwarded message:

From: JP Vasseur <[email-masked]>

To: Acee Lindem <[email-masked]>, "Abhay Roy (akr)"
<[email-masked]>

Cc: OSPF List <[email-masked]>

Thanks Acee, 

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

Thanks.

JP.

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. 

Thanks,
Acee 
[email-masked]

[email-masked]

---

From: Julien Meuric <[email-masked]>
Date: Sun, 07 Aug 2011 15:22:48 +0200

Hi Ramon.

My interference below.

Cheers,

Julien

Le 01/08/2011 10:11, Ramon Casellas a écrit :
> I'm afraid I don't understand the question, sorry :) Just in case, I 
> did not mean that TE enabled bit was needed. For simplicity, assume 
> all ABRs are TE enabled.
I think JP was referring to the discussion in Quebec. (If you missed it 
like me, audio archives may help to catch up.)
During the meeting, it seemed that "there was a need to know that a 
router was TE-enabled to avoid a signaling failure". If it is not known 
a priori, it is discovered at signaling time and crankback may be used. 
Nonetheless, knowing that the ABR is TE-enabled is not enough: the links 
to the destination may still not be TE-enabled, the available bandwidth 
may not be enough, the SRLG/administrative groups may not suit... Thus 
the extension would only save very few crankbacks, and might not be 
worth the effort.
But I note that this is not the use case you have in mind.

> below (paraphrasing parts of Section 1.2 RFC 3509), where an ABR has 
> no backbone connection
>
> . .
> . Area 0 .
> +--+ +--+
> ..|R1|.. ..|R2|..
> . +--+ .. +--+ .
> . .. .
> . +--+ .
> . Area1 |R3| Area2 .
> . +--+ +--+ .
> . .. |R4| .
> . . . +--+ .
> ....... .......
> Being an ABR, R3 can only consider summary-LSAs from the backbone when 
> building the routing table (according to section 16.2 of [RFC2328]), 
> so it will not have any inter-area routes in its routing table, but 
> only intra-area routes from both Area 1 and Area 2. Consequently, 
> according to section 12.4.3, R3 will originate into Areas 1 and 2 only 
> summary-LSAs covering destinations in the directly attached areas. At 
> the same time, router R2, as an ABR connected to the backbone, will 
> inject into Area 2 summary-LSAs describing the destinations in Area 0 
> (the backbone), Area 1 and other areas reachable through the backbone. 
> (...) This results in a situation where internal router R4 (or PCE) 
> calculates its routes to destinations in the backbone and areas other 
> than Area 1 via R2. (Rcas: although this may be addressed with a 
Thanks for providing this. If you believe this is an actual use case, it 
may be relevant to the Wenhu's I-D. You also mentions 2 significant 
things: it might be a corner case and existing solutions may already be 
enough...

> sequence within the IRO, listing areas 2 and 1. I would like a clean 
> way to consider R2 and R3 somehow differently. I believe here that 
> knowing the ABRs and the involved areas can be "a good thing" e.g. in 
> minimizing OF codes such as "minimum number of domains". of ocurse, if 
> there is no virtual link, I can deduce that R2 is attached to Area 0 
> since it is announcing summary LSAs for Area0 and areas other than 1 
> but I cannot rely on this.
It looks like there a lots of assumptions here. Per area-PCE function 
out of ABRs? If so, why using PCE? The PCE architecture already provides 
some solutions to that problem: PCE-capable ABR, virtual link between 
PCE and remote areas... Before moving forward, I think the context 
should be elaborated.

>
> - If PCE within Area1 does not support BRPC/VPST,
This reads to me like "if the existing solution is not supported, let us 
define a solution". :-) Both scenarios would require upgrade, so what 
motives another one?

> PCE in Area2 could explicitly select P2P paths from R3, selecting 
> those ABRs that are directly attached to Area1. Knowing that R2 is not 
> directly attached to Area1 allows PCE within area 2 to not request the 
> R2 path.
So it seems that it would help in reducing the number of requests to be 
sent. But what if, instead of R3, we have R3a and R3b? It would not help 
here, while VSPT does.

> somehow deduce a domain sequence and trigger the approporiate mechanism.
I like "simple". But adding a simple extension to address corner cases 
is still introducing complexity somewhere... Currently, the question is 
on the use cases for advertising area IDs: there might be some, but they 
are not obvious to me yet.
> self-contained in opaques :)
Opinions from others about this issue would be valuable.

> Research Associate - Optical Networking Area --http://wikiona.cttc.es
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Ramon Casellas <[email-masked]>
Date: Sun, 07 Aug 2011 19:49:09 +0200

Dear Julien, PCErs

See inline tagged [Ramon]

On 08/07/2011 03:22 PM, Julien Meuric wrote:
> I think JP was referring to the discussion in Quebec. (If you missed 
> it like me, audio archives may help to catch up.)
> router was TE-enabled to avoid a signaling failure". If it is not 
> known a priori, it is discovered at signaling time and crankback may 
> be used. Nonetheless, knowing that the ABR is TE-enabled is not 
> enough: the links to the destination may still not be TE-enabled, the 
> available bandwidth may not be enough, the SRLG/administrative groups 
> may not suit... Thus the extension would only save very few 
> crankbacks, and might not be worth the effort.
[Ramon] thanks for the explanation :) indeed, I consider this two 
different things

>> Consequently, according to section 12.4.3, R3 will originate into 
>> Areas 1 and 2 only summary-LSAs covering destinations in the directly 
>> attached areas. At the same time, router R2, as an ABR connected to 
>> the backbone, will inject into Area 2 summary-LSAs describing the 
>> destinations in Area 0 (the backbone), Area 1 and other areas 
>> reachable through the backbone. (...) This results in a situation 
>> where internal router R4 (or PCE) calculates its routes to 
>> destinations in the backbone and areas other than Area 1 via R2. 
>> (Rcas: although this may be addressed with a virtual link, as RFC3509 
>> mentions later on)
> Thanks for providing this. If you believe this is an actual use case, 
> it may be relevant to the Wenhu's I-D. You also mentions 2 significant 
> things: it might be a corner case and existing solutions may already 
> be enough...
>
[Ramon] I am not sure how "corner" this case is :) but I would guess 
that multi-homed areas, with one or more ABRs connected to area 0 and 
one or more ABRs connected to "neighbor" areas it's quite common, and 
may be improved? I understand that, being OSPF-TE and all areas having 
to be attached to Area 0, the restriction simplifies a lot of things 
with regard to arbitrary domain meshes. This is to me, as you may guess, 
a main argument _against_ what is proposed.

For reference below, consider Figure 1
       +-----------------------------+
       |        Area 0    (v)        |
       |                             |
+--A---B--+--C-----D---+--E---+
       |         |            |
       | Area 1  X    Area 2  | Area 3
       |         |            Z
       |         Y   (u)      |
       |         |            |
       +---------+------------+------+

>> minimizing OF codes such as "minimum number of domains". of ocurse, 
>> if there is no virtual link, I can deduce that R2 is attached to Area 
>> 0 since it is announcing summary LSAs for Area0 and areas other than 
>> 1 but I cannot rely on this.
> out of ABRs? If so, why using PCE? The PCE architecture already 
> provides some solutions to that problem: PCE-capable ABR, virtual link 
> between PCE and remote areas... Before moving forward, I think the 
> context should be elaborated.

[Ramon] I would like to decouple the roles of ABR and PCE. Although 
deploying PCEs in ABR has some advantages, it is not mandatory. We 
consider one PCE per area, which may have several ABRs. I would not 
exclude my case :) of "one area, one PCE in the middle" .
Moreover, if being area 2, we have the aforementioned one or more ABRs 
towards area 0, one or more ABRs towards area 1 (left/west) and one or 
more ABRs towards area 3 (right/east) wouldn't we need 2 or more PCEs 
(without considering the PCEs that also should be in the neighboring 
areas) ?

> This reads to me like "if the existing solution is not supported, let 
> us define a solution". :-) Both scenarios would require upgrade, so 
> what motives another one?
>
[Ramon] Agreed :) the fact that PCE with area 1 did not support BRPC was 
to simplify the example, in order for the upstream PCE to request only 
the "downstream segment".

>> those ABRs that are directly attached to Area1. Knowing that R2 is 
>> not directly attached to Area1 allows PCE within area 2 to not 
>> request the R2 path.
> So it seems that it would help in reducing the number of requests to 
> be sent. But what if, instead of R3, we have R3a and R3b? It would not 
> help here, while VSPT does.

[Ramon] Yes, multiple ABRs would almost imply BRPC for performance, yet 
the mapping of ABRs to neighboring areas remains the same problem.

Although I do understand your points  and current things can somehow be 
made to work, allow me a further example. Consider that we want to 
compute a Path from (u) to (v) and either we want to honor a domain 
sequence (2, 1, 0), or PCE2 does not know of PCE0, or other potential 
cases...

1.-  PCE2 will select PCE1 (any discovery or assume PCED OSPF 
extensions) and send the request.

2.- PCE2 will select PCE0.

3.- PCE0 will receive the request: RP(1, vspt=true) ENDPOINTS(u, v):

4.- It needs to apply BRPC so the upstream PCE will be able to 
reduce/trim paths.

- It needs to obtain the entry nodes to the domain. Note that there are 
three aspects: a) the domain sequence, the PCE sequence and the location 
reachability of endpoints.

  If it is only based on reachability, what prevents PCE0 from just 
replying the paths { {C, v} {D, v} } ?

  If it is based on reachability info plus PCE considerations it has 
several  choices:

     { A, B } ,
     { C, D } purely based on summaries,
     { A, B, C, D }
others?

Considering the example,  it would make sense to restrict the VSPT to A 
and B. To select a subset of ABRs (note that the "domain sequence" may 
or may not be present):

a) It could use the PCE1 address, but this is mixing things, the entity 
acting as a PCC could be located anywhere (e.g. a parent PCE or an NMS). 
It should use the source endpoint to select the entry border nodes.

b)  it could check the domain sequence (if present 2, 1, 0) identify the 
upstream domain (1) or map the requester PCE to a domain (1) using 
NEIGH_DOMAIN PCED extensions, but the previous point still applies

c)  it could check the domain sequence (if present 2, 1, 0) identify the 
upstream domain (1)  and select from the border nodes those that are 
attached to area 1 (A and B)

d) Other (existing? mechanisms) involve summary / external LSA, 
hopefully with different metrics, etc. can we guarantee this?

My personal preference is c) Of course, any subset of entry border nodes 
will "work" since PCE1 will end up filtering to its own exit nodes, but 
some paths may be wasted?

> is still introducing complexity somewhere... Currently, the question 
> is on the use cases for advertising area IDs: there might be some, but 
> they are not obvious to me yet.

[Ramon] The "cornicity" :) of the proposed use case is not clear yet, 
and the simple extension does not change in any form what is currently 
available. If you have the info, you may use it. If not, nothing changes.

>> plane is the right thing to do. Ideally (augmented) TED info should 
>> be self-contained in opaques :)

[Ramon] I guess this last sentence somehow wraps and summarizes my 
point. Feedback on this would be greatly appreciated, towards a 
self-contained augmented TED with border nodes and reachability info.

Thanks for reading (longer than expected)
R.

---

From: Ramon Casellas <[email-masked]>
Date: Sun, 07 Aug 2011 19:58:35 +0200

> 2.- PCE2 will select PCE0.
err s/PCE2/PCE1

> My personal preference is c) Of course, any subset of entry border 
> nodes will "work" since PCE1 will end up filtering to its own exit 
> nodes, but some paths may be wasted?
>
it should say "c). Of course"

R.

---

From: Wenhu Lu <[email-masked]>
Date: Mon, 8 Aug 2011 15:43:12 -0400

Hi Julien,
My comments inline. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Sunday, August 07, 2011 6:23 AM
To: Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes

Hi Ramon.

My interference below.

Cheers,

Julien

Le 01/08/2011 10:11, Ramon Casellas a écrit :
>> know that a router was TE-enabled to avoid a signaling failure . how 
I think JP was referring to the discussion in Quebec. (If you missed it like me, audio archives may help to catch up.) During the meeting, it seemed that "there was a need to know that a router was TE-enabled to avoid a signaling failure". If it is not known a priori, it is discovered at signaling time and crankback may be used. 
Nonetheless, knowing that the ABR is TE-enabled is not enough: the links to the destination may still not be TE-enabled, 

[wenhu] That is right. Router-level TE-enable info is too coarse. The draft covers the link cases exactly as your mentioned.

the available bandwidth may not be enough, the SRLG/administrative groups may not suit... 

[wenhu] The intra-area CSPF is designed to handle these. The draft doesn't reinvent them.

Thus the extension would only save very few crankbacks, and might not be worth the effort.

[wenhu] Savings? Methods like BRPC doesn't even work and is blind in terms of following area sequence.
Regards,
-wenhu

> below (paraphrasing parts of Section 1.2 RFC 3509), where an ABR has 
Thanks for providing this. If you believe this is an actual use case, it may be relevant to the Wenhu's I-D. You also mentions 2 significant
things: it might be a corner case and existing solutions may already be enough...

> but I cannot rely on this.
It looks like there a lots of assumptions here. Per area-PCE function out of ABRs? If so, why using PCE? The PCE architecture already provides some solutions to that problem: PCE-capable ABR, virtual link between PCE and remote areas... Before moving forward, I think the context should be elaborated.

> - If PCE within Area1 does not support BRPC/VPST,
This reads to me like "if the existing solution is not supported, let us define a solution". :-) Both scenarios would require upgrade, so what motives another one?

> directly attached to Area1 allows PCE within area 2 to not request the
So it seems that it would help in reducing the number of requests to be sent. But what if, instead of R3, we have R3a and R3b? It would not help here, while VSPT does.