Discussion list for Path Computation Element (PCE) - based architecture for computation of paths in MPLS and GMPLS

fabien.verhaeghe | 2 Apr 2007 15:45

Re: Switching type Constraint in PCEP

Hi Adrian,

>> However, where we seem to have arrived is that the PCEP I-D contains the 
>> protocol definition and "core" functional units. Other units that were 
>> identified in 4657 (such as XRO, objective funcions, ...) are going into 
>> seperate I-Ds. Following that model, the GMPLS-specific work definitely 
>> goes into a separate draft. As above, I am comfortable for that to be in 
>> the multi-layer I-D (perhaps we re-name to "GMPLS and multi-layer"?) to 
>> help keep the number of I-Ds manageable

Having a unique "GMPLS and multi-layer requirement" document seems a good 
idea to me.
If we'd have 2 seperate drafts I'm afraid there would be some overlapping 
just like for the switching type.

>> So my view (other will surely correct me  is that encoding type is 
>> only needed where the signal is unpacked for some reason. Typically, this 
>> only happens at end points, so the PCE function is to ensure that the 
>> destination interface is capable of decoding the signal and delivering 
>> the data. In general, it has been considered that the destination 
>> capabilities are either known to the ingress (guaranteed LSP setup 
>> success - you wouldn't even bother trying to set up an LSP to someone you 
>> knew couldn't understand you) or are not known in which case the LSP will 
>> either succeed or fail (but no amount of re-routing will help). Now, it 
>> *is* possible that different interfaces on the egress have different 
>> levels of support for encoding types, but this has generally been 
>> considered as very advanced and not worth optimising for.
>>
>> However, recent discussion has suggested that in certain technologies, 
>> signal regeneration also requires knowledge of the encoding type. This

(Continue reading)

headers

fabien.verhaeghe | 3 Apr 2007 13:07

Re: Switching type Constraint in PCEP

Hi Tomo,

I read your draft pointed by Dan that indeed contains some valuable 
information.
Especially in section 2.2:

"For the simplicity of the analysis in path consideration, the below
   basic assumptions are made when the LSP is created.

       (1) Switching capabilities (SC) of outgoing links from the
           ingress and egress nodes (link1-2 and link4-3 in Figure 1)
           must be consistent with each other.
       (2) SC of all transit links including incoming links to the
           ingress and egress nodes (link2-1 and link3-4) should be
           consistent with switching type of a LSP to be created.
       (3) Encoding-types of all transit links should be consistent
           with encoding type of a LSP to be created."

Point 2 and 3 seems to imply that a PCE needs to know both the switching and 
encoding type
of the LSP.
To me the information would typically be provided by the PCC (which knows 
what kind of LSP is being established)
using PCEP.
Am I misunderstanding something or do you agree?

Regards
Fabien

----- Original Message -----

(Continue reading)

headers

JP Vasseur | 3 Apr 2007 14:30

Fwd: ID Monitoring

Begin forwarded message:

From: JP Vasseur <jvasseur <at> cisco.com>

Date: March 29, 2007 3:32:18 PM EDT

To: PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou <at> alcatel-lucent.be>

Cc: pce <at> ietf.org

Subject: ID Monitoring

Hi Dimitri,

In order to move forward here ...

Could you list the set of items for which you'd like a clarification ?

Thanks.

JP.

<div>
<br><div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>From: JP Vasseur &lt;<a href="mailto:jvasseur <at> cisco.com">jvasseur <at> cisco.com</a>&gt;</div>
<div>Date: March 29, 2007 3:32:18 PM EDT</div>
<div>To: PAPADIMITRIOU Dimitri &lt;<a href="mailto:Dimitri.Papadimitriou <at> alcatel-lucent.be">Dimitri.Papadimitriou <at> alcatel-lucent.be</a>&gt;</div>
<div>Cc: <a href="mailto:pce <at> ietf.org">pce <at> ietf.org</a>
</div>
<div>Subject: ID Monitoring</div>
<div><br></div> <div>Hi Dimitri,</div>
<div><br></div>
<div>In order to move forward here ...</div>
<div><br></div>
<div>Could you list the set of items for which you'd like a clarification ?</div>
<div><br></div>
<div>Thanks.</div>
<div><br></div>
<div>JP.</div> </blockquote>
</div>
<br>
</div>

headers

Internet-Drafts | 3 Apr 2007 21:50

I-D ACTION:draft-ietf-pce-pcep-xro-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Path Computation Element Working Group of the IETF.

Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions
Author(s) : E. Oki, A. Farrel
Filename : draft-ietf-pce-pcep-xro-00.txt
Pages : 12
Date : 2007-4-3

The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering in Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

When a Path Computation Client (PCC) requests a PCE for a route, it
may be useful for the PCC to specify as constraints to the path
computation abstract nodes, resources, and Shared Risk Link Groups
(SRLGs) that are to be explicitly excluded from routes. Such
constraints are termed route exclusions.

The PCE Communication Protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs. This document presents PCEP
extensions for route exclusions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-xro-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-pce-pcep-xro-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
mailserv <at> ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-pce-pcep-xro-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Attachment: message/external-body, 135 bytes

Attachment (draft-ietf-pce-pcep-xro-00.txt): message/external-body, 68 bytes