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

[Wenhu Lu <[e-mail]>]

Hi Dhruv,
Please see my comments inline.

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

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.
[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. [phone]
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: Wenhu Lu [mailto:[e-mail]]
Sent: Wednesday, July 20, 2011 3:03 AM
To: Dhruv Dhody; 'JP Vasseur'
Cc: [e-mail]
Subject: RE: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

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:[e-mail]]
Sent: Thursday, July 14, 2011 9:49 PM
To: 'JP Vasseur'
Cc: Wenhu Lu; [e-mail]
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. [phone]
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:[e-mail]]
Sent: Thursday, July 14, 2011 3:50 PM
To: Dhruv Dhody
Cc: 'Wenhu Lu'; [e-mail]
Subject: Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

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.

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.

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. [phone]



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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Wenhu Lu
Sent: Thursday, July 14, 2011 6:46 AM
To: [e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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