Hi Eric, Huaimo,
I have updated the PCEP-LS draft with an appendix describing some examples,
which include the H-PCE case.
https://tools.ietf.org/html/draft-dhodylee-pce-pcep-ls-06#appendix-B.3
B.3. Between PCEs
As per Hierarchical-PCE [RFC6805], Parent PCE builds an abstract
domain topology map with each domain as an abstract node and inter-
domain links as an abstract link. Each child PCE may provide this
information to the parent PCE. Considering the example in figure 1
of [RFC6805], following LS object will be generated:
PCE1
----
LS Node
TLV - Local Node Descriptors
Sub-TLV - 1: Autonomous System: 100 (Domain 1)
Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)
LS Link
TLV - Local Node Descriptors
Sub-TLV - 1: Autonomous System: 100
Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)
TLV - Remote Node Descriptors
Sub-TLV - 1: Autonomous System: 200 (Domain 2)
Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract)
TLV - Link Descriptors
Sub-TLV - 7: IPv4 interface: 11.1.1.1
Sub-TLV - 8: IPv4 neighbor: 11.1.1.2
TLV - Link Attributes TLV
Sub-TLV(s)
LS Link
TLV - Local Node Descriptors
Sub-TLV - 1: Autonomous System: 100
Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)
TLV - Remote Node Descriptors
Sub-TLV - 1: Autonomous System: 200
Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract)
TLV - Link Descriptors
Sub-TLV - 7: IPv4 interface: 12.1.1.1
Sub-TLV - 8: IPv4 neighbor: 12.1.1.2
TLV - Link Attributes TLV
Sub-TLV(s)
LS Link
TLV - Local Node Descriptors
Sub-TLV - 1: Autonomous System: 100
Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)
TLV - Remote Node Descriptors
Sub-TLV - 1: Autonomous System: 400 (Domain 4)
Sub-TLV - 4: Router-ID: 44.44.44.44 (abstract)
TLV - Link Descriptors
Sub-TLV - 7: IPv4 interface: 13.1.1.1
Sub-TLV - 8: IPv4 neighbor: 13.1.1.2
TLV - Link Attributes TLV
Sub-TLV(s)
* similar information will be generated by other PCE
to help form the abstract domain topology.
Further the exact border nodes and abstract internal path between the
border nodes may also be transported to the Parent PCE to enable ACTN
as described in [I-D.dhody-pce-applicability-actn] using the similar
LS node and link objects encodings.
I hope this example clears up how PCEP-LS can be used between child PCE and
parent PCE. There is no "statically configuration" here.
If you or the WG has any other comment on
[https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/], please let us
know.
Regards,
Dhruv
From: Wunan (Eric)
Sent: 01 September 2016 15:12
To: Huaimo Chen <[email protected]>; Dhruv Dhody <[email protected]>
Cc: [email protected]
Subject: Re: [Pce] Some thoughts on H-PCE topology construction in Connections
and Accesses for H-PCE
Hi Huaimo, Dhruv,
I think this is an interesting and constructive discussion. Sorry for
intervening as non-author for neither of draft, since I'm glad to see it go
into deeper, technically.
@Dhruv, from my reading, Huaimo is emphasizing "procedure" missing and
"statically configuration". And you are saying "MAY carry" in PCEP-LS draft.
Maybe a little more detailed explanation for procedure or protocol extension
will help. Or missing does exist? So the WG can work on this?
@Huaimo, on the other side, how does your draft solve "statically
configuration"? Or better on that? Do I make any sense?
Regards
Eric
-----------------------------------------------------------------------------
Date: Thu, 1 Sep 2016 11:03:38 +0200
From: Dhruv Dhody <[email protected]<mailto:[email protected]>>
To: Huaimo Chen <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: Re: [Pce] Some thoughts on H-PCE topology construction in
Connections and Accesses for H-PCE
Message-ID:
<cab75xn7vdayrhejs8fzpzkzbazzn7ctk5opd1+atzjkqfwp...@mail.gmail.com<mailto:cab75xn7vdayrhejs8fzpzkzbazzn7ctk5opd1+atzjkqfwp...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"
Hi Huaimo,
You say...
Note that in the existing PCE-LS draft, there are not any procedures
defined for a child PCE to send and summarize the inter-domain
connections and access points to its parent PCE, and for a parent PCE
to receive and process the inter-domain connections and access points
from its child PCEs.
[PCEP-LS]? draft says...
Further [RFC6805] describes Hierarchical-PCE architecture, where a
parent PCE maintains a domain topology map. To build this domain
topology map, the child PCE MAY carry the border nodes and inter-
domain link information to the parent PCE using the mechanism
described in this document. Further as described in
[I-D.dhody-pce-applicability-actn], the child PCE MAY also transport
abstract Link-State and TE information from child PCE to a Parent PCE
using the mechanism described in this document to build an abstract
topology at the parent PCE.?
Thus I respectfully disagree with your assertion. I think the confusion for you
might be because you are expecting a new set of procedures and encoding to be
used especially for the purpose of H-PCE from child PCE to parent PCE. When
there is no need for a *new* set of procedure and encoding. The child PCE,
acting as a PCC, is responsible for deciding what information needs to be
transported to the parent PCE, and in this case can use the existing LS node
object to carry boundary node information and existing LS link object to carry
the inter-domain link. The LS node/link descriptor TLVs has information that
will identify that the node/link is boundary-node/inter-AS-link respectfully.
For ex, incase of inter-AS-link, the local node descriptor and remote node
descriptor will have different AS number clearly identifying that the link is
inter-AS.
I hope this clarifies the intention from the [PCEP-LS] point of view.
I do not have regular access to email this and coming week, so there might be
delay from my side in replying future post.
Thanks!
Regards,
Dhruv
On Wed, Aug 31, 2016 at 10:55 PM, Huaimo Chen
<[email protected]<mailto:[email protected]>>
wrote:
> Hi Everyone,
>
> Customers are very interested in the H-PCE and as we continue to
> develop the H-PCE we would like to minimize the amount of manual
> configurations. Two key areas for better automation are:
>
> 1. Advertisement of inter-domain connections (inter-domain links
> and
> ABRs) from child PCE to parent PCE
> 2. Construction of the parent PCE TED based on the advertisement
>
> Existing methods for these two objectives require manual efforts.
> Some automation is possible if the parent PCE can also join the IGP
> instance of a child PCE domain to learn inter-domain TE link info, but
> not all operators would want to allow this. It was expected that this
> type of information would be statically configured. As the numbers of
> domains increase that a parent PCE is managing, it will become a
> configuration burden to update the parent PCE manually. The BGP-LS may
> be another option but I am not sure all operators will want to use the
> BGP-LS. Why not continue to use PCEP with extensions if it is being used for
> the H-PCE.
>
> In the existing PCEP, there are not any procedures or data defined
> for a child PCE to send and summarize the connections and access
> points to its parent PCE, and for a parent PCE to receive and process
> the connections and access points from its child PCEs to construct the
> parent PCE TED. The extensions proposed in our draft "Connections and
> Accesses for Hierarchical PCE?
> https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/
> specify the procedures and define the data, in which a child PCE
> advertises and summarizes its inter-domain connections and access
> points to its parent PCE, which constructs the parent PCE TED.
>
> Note that in the existing PCE-LS draft, there are not any
> procedures defined for a child PCE to send and summarize the
> inter-domain connections and access points to its parent PCE, and for
> a parent PCE to receive and process the inter-domain connections and access
> points from its child PCEs.
>
> What our draft proposed seems a new work. I hope for good
> discussions on this topic on the list.
>
> Best Regards,
> Huaimo
>
>
> _______________________________________________
> Pce mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/pce
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/pce/attachments/20160901/e7a65397/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
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
