Hi Dhruv,
Please see my comments inline.
________________________________
From: Dhruv Dhody [mailto:[email protected]]
Sent: Wednesday, July 20, 2011 2:33 AM
To: Wenhu Lu; 'JP Vasseur'
Cc: [email protected]
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. +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: Wenhu Lu [mailto:[email protected]]
Sent: Wednesday, July 20, 2011 3:03 AM
To: Dhruv Dhody; 'JP Vasseur'
Cc: [email protected]
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:[email protected]]
Sent: Thursday, July 14, 2011 9:49 PM
To: 'JP Vasseur'
Cc: Wenhu Lu; [email protected]
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 protected]]
Sent: Thursday, July 14, 2011 3:50 PM
To: Dhruv Dhody
Cc: 'Wenhu Lu'; [email protected]
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.
+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 protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Wenhu Lu
Sent: Thursday, July 14, 2011 6:46 AM
To: [email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
