Subject: [Pce] ANN: New Version Notification for draft-zhang-pce-hierarchy-extensions-01.txt

From: Ramon Casellas <[email-masked]>
Date: Fri, 14 Oct 2011 10:12:31 +0200

Dear PCErs,

FYI, a new version of draft-zhang-pce-hierarchy-extensions has been uploaded.
This document defines PCEP extensions for H-PCE (see below).

It is a minor update, and, most importantly, a lot of open issues remain.
In this sense, your comments / suggestions are welcome.

The current draft already proposes some protocol extensions / encodings to the
high-level procedures detailed in the companion framework document. Recent
exchanges seem to imply that there is room to revisit requirements and
procedures,including

* (Parent) TED management: it can be argued that the framework document relies
   on basic domain connectivity, precluding TE aggregation mechanisms. This
   seems to be a topic of debate. It has been mentioned in private conversations
   that it should be a decision of the network operator (based on policies or
   whatever criterion) to decide the level of information exchange allowed. It
   clearly seems to depend on the actual scenario (e.g. multi-area WSON vs
   Inter-AS/carriers)

* In any case, decoupling TED management from path computation has been a
   design criterion within the PCE architecture and this should be applied also
   to the solutions document. Several mails have hinted the idea of (separate?)
   approaches to (hierarchical) TED management (cfr. Olivier/Oscar mails) and
   leaving TED management out of scope (including wrapping TED-related messages
   out of PCEP / PCNtf). It may be difficult if both functions (path computation
   and TED management) are slightly coupled (border node identification,
   endpoint localization and topology aggregation for domain sequence selection,
   to name a few in which an IGP-based TED may not be sufficient)

* Domain representation: the role of domains and domain identifiers is clearly
   important. We should align with e.g. draft-dhruv on domain sequence, avoid
   new encodings for domains which could re-use Route sub-objects, etc.

* Alternative approaches (Dhruv) suggest to keep the Parent-PCE’s topology
   graph free of BNs (Boundary Nodes) and inter-AS TE link; it being composed
   only of neighbor domain adjacency.

* OF codes: new requirements arise regarding OF codes, including the
   consideration of actual OF codes (e.g. minimize domain crossing) and
   policies affecting them (e.g. do not allow domain re-enter).  Additionally,
   there seems to be a need to be able to specify the OF codes to apply at both
   levels, not only at the parent level but also the child's (i.e. intra-domain
   level)

* Reachability: the current fwk/pcep drafts rely on polling to locate
   endpoints. This does not preclude some form of caching, but alternative
   solutions based on notifications/announcements of endpoint (prefixes) have
   been mentioned.

* Exclusions: exclusions need to take into account domains.

* Other?...

Dan mentioned that discussion and agreement of the above, will help create
requirements that will allow us define the Protocol extensions, including PCEP
extensions, encoding, error handling and manageability. For this, Dan plans to
leave the Framework document open in case new requirements arise.

Best regards,

Ramon, on  behalf of the draft co-authors

-------------------------------------------------------------------------
New Version Notification for draft-zhang-pce-hierarchy-extensions-01.txt

A new version of I-D, draft-zhang-pce-hierarchy-extensions-01.txt has been successfully submitted by Fatai Zhang and posted to the IETF repository.

Filename:	 draft-zhang-pce-hierarchy-extensions
Revision:	 01
Title:		 Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)
Creation date:	 2011-10-13
WG ID:		 Individual Submission
Number of pages: 19

Abstract:
    The hierarchical Path Computation Element (PCE) architecture, defined
    in the companion framework document [I-D.ietf-pce-hierarchy-fwk],
    allows the selection of an optimum domain sequence and the optimum
    end-to-end path, to be derived through the use of a hierarchical
    relationship between domains.

    This document defines the Path Computation Element Protocol (PCEP)
    extensions for the purpose of implementing hierarchical PCE
    procedures which are described the aforementioned document.

-- 
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: "Daniel King" <[email-masked]>
Date: Fri, 14 Oct 2011 11:46:33 +0100

Great summary, thanks Ramon. 

As ever WG contributions are always actively sought, however with H-PCE we
would love to hear more operator/provider feedback regarding the
applications, procedures and extensions being discussed! 

We plan to summarise a number  of open H-PCE  issues and discuss  them
during our WG at IETF 82 (Taipei) next month. We will also organise a
separate discussion at IETF 82 to give us time to go into more detail for
specific areas. Please unicast me if you are interested in participating,
and mentioning your H-PCE topic of interest. 

Br, Dan. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon
Casellas
Sent: 14 October 2011 09:13
To: [email-masked]
Subject: [Pce] ANN: New Version Notification for
draft-zhang-pce-hierarchy-extensions-01.txt

Dear PCErs,

FYI, a new version of draft-zhang-pce-hierarchy-extensions has been
uploaded.
This document defines PCEP extensions for H-PCE (see below).

The current draft already proposes some protocol extensions / encodings to
the high-level procedures detailed in the companion framework document.
Recent exchanges seem to imply that there is room to revisit requirements
and procedures,including

* (Parent) TED management: it can be argued that the framework document
relies
   on basic domain connectivity, precluding TE aggregation mechanisms. This
   seems to be a topic of debate. It has been mentioned in private
conversations
   that it should be a decision of the network operator (based on policies
or
   whatever criterion) to decide the level of information exchange allowed.
It
   clearly seems to depend on the actual scenario (e.g. multi-area WSON vs
   Inter-AS/carriers)

* In any case, decoupling TED management from path computation has been a
   design criterion within the PCE architecture and this should be applied
also
   to the solutions document. Several mails have hinted the idea of
(separate?)
   approaches to (hierarchical) TED management (cfr. Olivier/Oscar mails)
and
   leaving TED management out of scope (including wrapping TED-related
messages
   out of PCEP / PCNtf). It may be difficult if both functions (path
computation
   and TED management) are slightly coupled (border node identification,
   endpoint localization and topology aggregation for domain sequence
selection,
   to name a few in which an IGP-based TED may not be sufficient)

* Domain representation: the role of domains and domain identifiers is
clearly
   important. We should align with e.g. draft-dhruv on domain sequence,
avoid
   new encodings for domains which could re-use Route sub-objects, etc.

* Alternative approaches (Dhruv) suggest to keep the Parent-PCE’s topology
   graph free of BNs (Boundary Nodes) and inter-AS TE link; it being
composed
   only of neighbor domain adjacency.

* OF codes: new requirements arise regarding OF codes, including the
   consideration of actual OF codes (e.g. minimize domain crossing) and
   policies affecting them (e.g. do not allow domain re-enter).
Additionally,
   there seems to be a need to be able to specify the OF codes to apply at
both
   levels, not only at the parent level but also the child's (i.e.
intra-domain
   level)

* Reachability: the current fwk/pcep drafts rely on polling to locate
   endpoints. This does not preclude some form of caching, but alternative
   solutions based on notifications/announcements of endpoint (prefixes)
have
   been mentioned.

* Other?...

Dan mentioned that discussion and agreement of the above, will help create
requirements that will allow us define the Protocol extensions, including
PCEP extensions, encoding, error handling and manageability. For this, Dan
plans to leave the Framework document open in case new requirements arise.

Best regards,

A new version of I-D, draft-zhang-pce-hierarchy-extensions-01.txt has been
successfully submitted by Fatai Zhang and posted to the IETF repository.

Filename:	 draft-zhang-pce-hierarchy-extensions
Revision:	 01
Title:		 Extensions to Path Computation Element Communication
Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)
Creation date:	 2011-10-13
WG ID:		 Individual Submission
Number of pages: 19

Abstract:

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

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