From pce-bounces@lists.ietf.org Mon Oct 01 06:32:38 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IcIZH-0004xh-Hy; Mon, 01 Oct 2007 06:32:03 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IcIZG-0004wv-K2
	for pce-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 06:32:02 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIZG-0004vU-7U
	for pce@ietf.org; Mon, 01 Oct 2007 06:32:02 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcIZE-000797-Dk
	for pce@ietf.org; Mon, 01 Oct 2007 06:32:02 -0400
Received: from [88.96.235.138] (helo=cortex.aria-networks.com)
	by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IcIZD-0008AJ-90
	for pce@ietf.org; Mon, 01 Oct 2007 10:31:59 +0000
Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by
	cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 1 Oct 2007 11:31:57 +0100
Message-ID: <074701c80416$48f22700$0200a8c0@your029b8cecfe>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <pce@ietf.org>
Date: Mon, 1 Oct 2007 11:28:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 01 Oct 2007 10:31:57.0902 (UTC)
	FILETIME=[4B4A6EE0:01C80416]
X-Originating-Heisenberg-IP: [88.96.235.138]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119
Cc: 
Subject: [Pce] Security directorate review of
	draft-ietf-pce-interas-pcecp-reqs-03
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hi,

We asked the Security Area Directorate to provide us with an early review of 
draft-ietf-pce-interas-pcep-reqs. Recently, a fair number of I-Ds from PCE 
and CCAMP have been falling at the security hurdle during IESG review. This 
seems to be particularly the case for inter-AS work, so we thought that we 
should try to get some feed-back before we go to WG last call, and see if we 
can produce a draft that better addresses the Security AD's concerns.

We received comments from Sandy Murphy and Pasi Eronen as shown below. The 
chairs will be working with the document authors to revise the text to 
address the issues raised, but we would all be more than grateful for other 
comments and assistance.

Thanks,
Adrian

+++++ <begin Sandy Murphy>

This draft specifies the requirements for a PCE communication
protocol, i.e., a protocol between PCC and PCE or inter-PCE, when the
communication is taking place across AS boundaries.  This AS boundary
could be within one service provider or may be between service
providers.  The PCEs compute paths for the establishment of LSPs
satisfying PCC provided constraints.

This document refers to the security considerations of RFC4657, which
mandates support for protections agains spoofing, snooping and DOS
between the entities.

The example given discusses communication that spans ASs - a PCE1 in
AS1 makes a request of a PCE2 in AS2, who asks a PCE3 in AS3 .  The
reply from AS3 gets augmented by info from the AS2 before PCE2 replies
to PCE1.

This sounded like they anticipate protocols that could lead to
PCE2/AS2 being able to inject bogus information supposedly from AS3
in what it passes to PCE1/AS1 (a la BGP mis-originations).  This is
only an example, but the intent of the protocol is to return the
inter-AS path of the computed LSP, so this behavior is likely.  The
security requirements seem to address only hop-by-hop security - there
are no requirements to ensure that the PCE providing information for
which it is not "authoritative" is providing legitimate info.  I.e.,
there's no end-end model of protecting the data.

The security considerations section also note:

   Additionally, two aspects of operations specific to inter-AS PCEs
   require careful security considerations.  There are two modes of
   determining peering PCEs across the AS boundary manual
   configuration and auto-discovery.  In the manual mode, mechanisms
   for securely exchanging manually confgiured authentication key or
   key sets across SP boundaries MUST be defined.  For example, the
   authentication key May be manually configured for each PCE peer and
   PCE registration MAY be served as a mechanism for securely
   exchanging authentication keys across SP boundaries.  In the
   auto-discovery mode, inter-as PCEs can be auto-discovered only if
   it is configured to participate in that discovery scope.


   An inter-AS PCE is not necessarily able to establish PCEP sessions
   with the discovered PCEs in its scope(s), it MUST be able to
   authenticate with the peering inter-AS PCE, therefore mechanisms
   for securely exchanging authentication keys across SP boundaries
   MUST also be defined in this case.  Furthermore, the auto-discovery
   process itself MUST also be authenticated.

The first paragraph refers to manual and auto-discovery of PCEs and
the problems this creates in an inter-AS situation.  Other pce wg
drafts/RFCs give rough orders of magnitude of 1000s of PCCs
communicating with one PCE and one PCC communicating with 100s of
PCEs.  There's some confusion as to the distinction between PCCs and
PCEs in an inter-PCE communications.  So it is unclear how many
inter-AS inter-PCE connections one PCE might have.  But it does seem
clear that manual keying could be unscalable in inter-PCE
environments.

I do not know what the draft means by saying that PCE registration could
serve to exchange keys across SP boundaries - does it mean in the
initial exchange of open messages?

Auto-discovery mode needs additional consideration.  RFC4674 already
says that an auto-discovery protocol must ensure authenticity,
integrity, and confidentiality, as well as authorization of the PCC.
The present definitions of auto-discovery are extensions on ospf and
isis, but that won't work here.  Seems best to mandate an automated
key management here - perhaps that was the intent of saying "securely
exchanging authentication keys".

        ************************************************************
        Do pay attention to RFC4107  and Sam Hartman's message to the
        wgchairs list reminding them/us of same.
        ************************************************************


Note that RFC4657 also says:

   Key management MUST be provided by the PCECP to provide for the
   authenticity and integrity of PCECP messages.  This will allow
   protecting against PCE or PCC impersonation and also against message
   content falsification.

I don't know that it actually meant to mandate that the PCECP had to
provide key management itself as part of the protocol.  But key
management of some sort is clearly indicated.  It just doesn't say
whether that means manual or automated.


===================================================================


I also took a look at the PCE communication protocol draft.

draft-ietf-pce-pcep-08.txt

This draft's security consideration section does not refer to the
security considerations section of RFC4657 (PCEP generic requriements),
which mandates that

   The PCC-PCE communication protocol MUST include provisions to ensure
   the security of the exchanges between the entities.  In particular,
   it MUST support mechanisms to prevent spoofing (e.g.,
   authentication), snooping (e.g., preservation of confidentiality of
   information through techniques such as encryption), and Denial of
   Service (DoS) attacks (e.g., packet filtering, rate limiting, no
   promiscuous listening).  Once a PCC is identified and authenticated,
   it has the same privileges as all other PCCs.

This draft does not mandate any authentication mechanism.  It does
RECOMMEND use of TCP-MD5.

        ************************************************************
        Note: TCP-MD5 is technically weak.  It's use in BGP required
        a special process exception.  It is unlikely such an exception
        would be granted to a new use.
        ************************************************************

It would appear that this draft and RFC4657 are referring to
hop-by-hop security only.

Note: PCEP runs over TCP.  It adopts the severe response model BGP
uses -- it terminates a session if a mal-formed message appears or
the TCP connection fails.  This means it is susceptible to TCP
off-path guesses at sequence numbers leading to RSTs or out-of-order
data being accepted.  I don't think a TLS/SSL level protection would
protect the protocol.

This draft differentiates behavior on receipt of some messages (e.g.,
NOTIFICATION) depending on whether the sender was a PCC or a PCE.  I
don't see that the PCC/PCE difference is communicated anywhere.  The
draft usually speaks only of PCC-PCE communication, not inter-PCE
communication.  However, RFC4674 notes that it (the rfc) makes no
distinction between a PCC and a PCE acting as a PCC (because it was
making a request inter-PCE).  The same may be here also, so it may be
possible that the role of the peer is maintained in connection
state.  But it is not clear that the PCE peers in the connection don't
take on both PCC and PCE roles over time, so I'm not positive that
helps.


===================================================================

I also took a look at:

rfc4674 (Requirements for PCE Discovery)


This RFC says:

   It is also important to note that the notion of a PCC encompasses a
   PCE acting as PCC when requesting a path computation of another PCE
   (inter-PCE communication).  Hence, this document does not make the
   distinction between PCE discovery by PCCs and PCE discovery by PCEs.

The rest of the text refers to PCCs discovering PCEs, without
distinguishing whether these are the "real" PCCs or PCEs acting as
PCCs.  This makes it difficult to determine the usual operational
model for inter-AS discovery: do "real" PCCs discover the PCEs who are
inter-AS capable in their own domain so that the inter-AS PCE can then
discover the inter-AS PCE in a neighboring AS, or can a "real" PCC
directly discover the remote ASs inter-AS PCE?  The difference could
make a difference in deciding on the scaling needed in a key
management scheme.

Note that the rfc gives order of magnitude of what the discovery
design must support:

   - Number of PCCs discovering a given PCE: 1000
   - Number of PCEs to be discovered by a given PCC: 100

But it is unclear if these are the "real" PCCs or includes PCEs that
are acting as PCCs

   The PCE discovery mechanism MUST allow for policies to restrict the
   discovery scope to a set of authorized domains, to control and
   restrict the type and nature of the information to be disclosed, and
   also to filter and translate some information at domains borders.

   Such inter-AS PCE discovery must be carefully controlled.  For
   security and confidentiality reasons, particularly in an inter-
   provider context, the discovery mechanism MUST allow the discovery
   scope to be limited to a set of ASs and MUST also provide control of
   the PCE information to be disclosed across ASs.  This is achieved by
   applying policies (see also Section 4.4).  This implies the
   capability to contain a PCE advertisement to a restricted set of one
   or more ASs, and to filter and translate any PCE parameter (PCE
   domains, PCE inter-domain functions, PCE capabilities, etc.) in
   disclosures that cross AS borders.

These references to translation are probably intended to apply in cases
like the example given: "translate" what is communicated internally to
something else when communicated externally.

But other references make it sound like some of the discovery information
might come from another domain down the line:

   Also the PCE discovery mechanism MUST allow discovery of the inter-
   domain functions of a PCE, i.e., whether a PCE can be used to compute
   or to take part in the computation of end-to-end paths across domain
   borders.  The inter-domain functions include nonexhaustively: inter-
   area, inter-AS and inter-layer path computation.  Note that these
   functions are not mutually exclusive.

   Note that the inter-domain functions are not necessarily inferred
   from the set of domains where a PCE has visibility.  For instance, a
   PCE may have visibility limited to a single domain, but may be able
   to take part in the computation of inter-domain paths by
   collaborating with PCEs in other domains.

In such a case, "translating" information starts to sound more
troubling - it could be "translating" information which came from some
other domain.  The hop-by-hop integrity protections would be useless
against changes made by the peer PCE.

+++++ <end Sandy Murphy>

+++++ <begin Pasi Eronen>

I was assigned to do an early Security Directorate review of
draft-ietf-pce-interas-pcecp-reqs-03 ("Inter-AS Requirements for
the Path Computation Element Communication Protocol (PCECP)").

This is certainly one of the most difficult SecDir review
assignments I've gotten so far. The document itself is only 13
pages, but it required quite a lot of background reading; and the
security issues seem to span a rather large set of documents, none
of which can be fully considered alone.

So, a disclaimer is in order: I'm not very familiar with the topic
area (PCE, MPLS), and this review is in no sense thorough or
exhaustive.

In general, the documents seem rather well written, and consider
security broadly (not just cryptographic mechanisms for protecting
messages, but also e.g. revealing sensitive information to
authenticated communication nodes, etc.).

However, I identified at least the following topics that IMHO
require further clarification:


1) Interaction between PCE discovery and PCEP communication security

It looks like there's a rather large disconnect between the PCE
discovery drafts (which assumes that PCCs can dynamically and
automatically discover PCEs) and the actual PCE protocol document
(which uses communication security mechanisms that essentially
require manual configuration of each PCC-PCE relationship).

Or in other words: if you use TCP-MD5, and anyway have to manually
configure the shared secrets and PCC/PCE IP addresses at each
PCE/PCC, the benefits of having a discovery mechanism are quite
limited (the capability part might still be useful, though).

Using something else than TCP-MD5, such as IPsec, does not
fundamentally change the situation. If you use shared secrets
(that are really pairwise shared secrets, and not shared by all
devices in a domain), they need pairwise configuration. Some
kind of PKI might reduce the configuration work from O(N^2)
to O(N), but that has challenges, too.


2) PCE discovery/communication security, inter-AS case

The previous issue is likely to be more complex in the inter-AS
case.

The interas-pcep-reqs draft basically states that "mechanisms for
securely exchanging manually configured authentication key ...
across SP boundaries MUST be defined". However, it's not clear
whether this mechanism is intended to be (or even can be) purely
a network protocol, or whether it's more a "ceremony" or
"procedure" involving off-line human interaction.

Or in other words: is the intent to define, for example, a key
management protocol for TCP-MD5 (possibly based on existing
security relationships in e.g. BGP or IGP)? Or something else
completely?


3) Use of TCP-MD5

The PCEP draft specifies TCP-MD5 as the recommended security
mechanism.  I am not, at this time, suggesting that it would be
better to use X instead -- but it's probable that some else will,
and that any new protocol attempting to use TCP-MD5 will raise
some questions. At least a good explanation is likely to be required.


4) IPsec details

The PCEP draft basically says that IPsec MAY be used.  This
is nowhere near enough; see e.g. draft-bellovin-useipsec-06
for a starting point.


5) PCE policies vs. message authentication

One topic that has received relatively little discussion is the
relationship of policies based on the identity or other attributes
(such as AS) of a PCC, and the cryptographic mechanisms for
authenticating messages. The challenge is that the policy at
the PCE might be expressed in terms of identifiers/properties
of PCC that are not readily supplied (or authenticated) by the
PCC-PCE message authentication mechanism.

For example, if a PCE configures TCP-MD5 key to protect all
messages coming from 192.0.2.1 with key "secret", it would be
straightforward to have a PCE policy "for requests coming from
PCC 192.0.2.1, avoid paths with (some criteria)".

However, a policy "for requests coming from Example Operator Inc.,
avoid paths with..." (or "...coming from AS 1234...") would require
additional information (possibly via manual configuration) to
determine how the request should be processed (e.g., mapping
authenticated PCC identity to the identifier/property used in the
policy in a secure fashion).

Such a manual configuration is certainly doable -- especially in
case where all the other information (such as shared secrets) is
manually configured as well -- but is slightly more problematic if
PKI-based authentication is envisioned. If the certificate doesn't
contain the identifiers/properties you need, per-PCC manual
configuration might still be needed. This may also limit the types
of policies you can easily use.


6) Policies in different PCEs and verifying correct operation

One important manageability consideration in RFC 4655 is verifying
correct operation, in particular assessing the validity of the
computed paths.  This is likely to be especially challenging in
inter-AS case, as any single operator does not necessarily have
management access to all the PCEs involved in a computation.

This is further complicated by inter-AS rewriting/reinterpretation of
parameters, constraints, and policies. Such rewriting/reinterpretation
could also include malicious intent, and thus may be a security issue.

+++++ <end Pasi Eronen> 




_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Mon Oct 01 08:44:02 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IcKc3-0004vt-8i; Mon, 01 Oct 2007 08:43:03 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IcKc1-0004uI-Ob
	for pce-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 08:43:01 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IcKbx-0004pN-Vw
	for pce@ietf.org; Mon, 01 Oct 2007 08:42:58 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcKbv-0002ej-Es
	for pce@ietf.org; Mon, 01 Oct 2007 08:42:57 -0400
X-IronPort-AV: E=Sophos;i="4.21,216,1188770400"; 
	d="scan'208,217";a="154578092"
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 01 Oct 2007 14:42:54 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l91Cgsvo006404; 
	Mon, 1 Oct 2007 14:42:54 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com
	[144.254.231.71])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l91CgYG9021724; 
	Mon, 1 Oct 2007 12:42:52 GMT
Received: from xmb-ams-338.cisco.com ([144.254.231.83]) by
	xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 1 Oct 2007 14:42:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks...
Date: Mon, 1 Oct 2007 14:44:05 +0200
Message-ID: <1F2FBF50FB955441A11316BAE835CED4042D1DB2@xmb-ams-338.emea.cisco.com>
In-Reply-To: <46FD5A18.2080505@grotto-networking.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical
	Networks...
Thread-Index: AcgCCFAxVs5keUR2TRWXpXsR0QfyhgCFxxNw
From: "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>
To: "Greg Bernstein" <gregb@grotto-networking.com>
X-OriginalArrivalTime: 01 Oct 2007 12:42:35.0460 (UTC)
	FILETIME=[8AD6E040:01C80428]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=27622; t=1191242574;
	x=1192106574; c=relaxed/simple; s=amsdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=giomarti@cisco.com;
	z=From:=20=22Giovanni=20Martinelli=20(giomarti)=22=20<giomarti@cisco.com>
	|Subject:=20RE=3A=20[Pce]=20Some=20key=20issues=20with=20Wavelength=20Swi
	tched=20Optical=20Networks... |Sender:=20;
	bh=L+NnBxiPMJuwFBqBiMY4rFl/bi2QzhsR7RoNGbquvhA=;
	b=GyW9MG6R+p9aAZPSlsDnLOshKQ3E84DsWLpIYOTKnSub255sqdMcplX7jjR91xPMW2lqDEiQ
	h7Fi5LPCS+RTg//bq1iLBm0+a585HnaarrV9cSWfMSeIDbmZmGif5wDq;
Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ad21aece51aeebf80192250df67eab8a
Cc: ccamp <ccamp@ops.ietf.org>, pce@ietf.org
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2105766413=="
Errors-To: pce-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============2105766413==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C80428.8A87C582"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C80428.8A87C582
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Greg,
=20



________________________________

	From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
	Sent: venerd=EC 28 settembre 2007 21.47
	To: Giovanni Martinelli (giomarti)
	Cc: ccamp; pce@ietf.org
	Subject: Re: [Pce] Some key issues with Wavelength Switched Optical =
Networks...
=09
=09
	Hi Giovanni, thanks for the close read.  Looks like you caught some =
problems with the text.  See below for comments.
=09
	Giovanni Martinelli (giomarti) wrote:=20

		Hi Greg,
		=20
		Sorry for the delay in replying. I'm working on this topic since a =
while so yes, it's interesting. Before going on specific issue I would =
have some question/clarification regarding the draft itself.=20
		=20
		=20
		* Within Abstract and the following.
		You don't talk about Optical Cross Connects (OXC) is something missing =
or understated somewhere?

	-->Whoops.  We were trying to find a more general term to include both =
ROADM (usually a highly asymmetric fabric) and an OXC (a completely =
symmetric fabric, e.g., any ingress to any egress), but we seemed to =
have gone with using the ROADM terminology to include both cases.  =
Talked with some equipment makers that planned/make "switches" that =
seemed to incorporate both so we made sure the model could deal with =
both sparse and dense potential connectivity. Diego had some terminology =
ideas but lately his e-mails have been bouncing back to me.  Any =
suggestions are appreciated, but we are including both ROADM and OXCs.=20
	=20

My doubt was coming from the ROADM definition in section 2 and picture =
used later on the draft. At  least in my understanding the OXC is a =
general case for ROADM (sort of multi-degree ROADM) but ok, it's a =
matter of terminology.

=20

		=20
		=20
		* Section 3.1 where you state:=20
		"A fixed mapping between the=20
		GMPLS label space and these ITU-T WDM grids as proposed in [Otani] "
		Does it implies a sort of network level label space? How relate with =
usual local label significance?

	--> This mapping gives a mapping between labels and wavelengths/lambda, =
just like in the SONET/SDH case we mapped the ITU-T G.707 "S, U, K, L, M =
" identification of SDH time slots to a label format in RFC4606 and =
again this was done in RFC4328 to map G.709 digital wrapper time slot =
identification into a technology specific label format.  In RFC3471 for =
lambda switching we just get a 32 bit integer with no meaning attached. =
Every network and every node could potentially map labels to lambdas in =
a different way. In [Otani] they are following the RFC4606 and RFC4328 =
lead and using the ITU-T DWDM and CWDM lambda grid standards to give a =
fixed association between labels and lambdas just like between labels =
and TDM time slots in the SDH/ODU case.
=09
	This doesn't change the local significance of labels. In the wavelength =
switched optical case that is influenced by the presence or absence of =
wavelength converters.=20
	=20

Ok. Local significance  but global semantic (as pointed out by Adrian in =
a previous mail).=20


		=20
		=20
		* Section 3.4 Wavelength Converters=20
		"Current or envisioned contexts for wavelength converters are : ..."
		Could we think to a description/model for wavelength converter that is =
technology agnostic? Simply something like: full conversion capability, =
partial conversion capability with some constrains, and may be others.

	--> The difference, between the all optical techniques and the OEO =
based techniques makes that difficult.
=09

		=20
		=20
		* Section 3.4. the following:=20
		"4. Wavelength converters that are O-E-O based will have a restriction =

		based on the modulation format and transmission speed"=20
		Not clear to me the type of restriction here when OEO happens... =
probably I'm missing what you mean here.

	--> For example a typical O-E-O based wavelength converter would be =
build around a 3R regenerator with a tunable laser. A 3R regenerator =
cares about the modulation type say NRZ or RZ (and which flavor), and =
the symbol rate since its also doing retiming. An all optical wavelength =
converter will be fairly independent of these issues (except when we =
look at impairment factors). Hence the OEO wavelength is going to be =
more signal specific than the all optical.=20
	=20

ok more clear now, although it would be nice having a general model as =
you marked  with TBD.=20


		=20
		=20
		* Section 4.1 when you talk about Lightpath temporal characteristics:
		"Lightpath connection duration has typically been thought of as=20
		approximately three time frames: "=20
		and the following you define: dynamics, pseudo-static, static.
		Why there's a need of this classification? When you us Short/long is =
compared to what?

	--> In most of the research literature and in optimization practice =
different techniques are typically used in the dynamic versus static (or =
psuedo static cases).  In MPLS there is minimum interference routing =
optimization techniques for the dynamic case. For the static case I =
could apply multi-commodity flow optimization techniques to a batch of =
connections.  In the RWA literature there is a similar differentiation.  =
Exactly what information could be sent to help PCE differentiate I'm not =
sure. In the case of static, batch optimization we can just use the =
existing concurrent optimization hooks in PCE. For an individual =
lightpath request it seemed that it would be helpful to know how long =
the connection would last so we'd know how much computational effort we =
might want to put into optimize it.=20
	=20

ok, clear. I still have doubt about quantifiers but fine for the moment.
=20
Thanks,
Giovanni


		=20
		=20
		minor typo on your mail below: point (c) rfc4328 (not 4238) right?

	--> Yes.  The G.709 signaling extensions RFC.
=09

		=20
		Thanks,
		Giovanni

	=09
		=20

________________________________

			From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
			Sent: gioved=EC 27 settembre 2007 1.42
			To: ccamp; pce@ietf.org
			Subject: [Pce] Some key issues with Wavelength Switched Optical =
Networks...
		=09
		=09
			Hi folks, I haven't seen too many comments on our draft "Framework =
for GMPLS and PCE Control of Wavelength Switched Optical Networks" ( =
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit=
ched-01.txt). So I figured I'd point out some potentially controversial =
issues that the draft brings up.=20
		=09
			(a) The draft brings up models for the following WDM network =
elements:
		=09

			1.	WDM links=20
			2.	Optical transmitters
			=09
			3.	Wavelength Converters and OEO regenerators=20
			4.	ROADMs, FOADMs, optical splitters and combiners.=20

			    For items (3) and (4) we are taking the modeling lead rather than =
some other SDO.  And for ROADMs, in particular, we going beyond the =
classic ITU-T "fabric" model (M.3100) which has been the mainstay of any =
connection oriented switch (TDM, ATM, MPLS).
		=09
			(b) The draft brings up three (not one, not two, but three) different =
computational models for RWA which can impact GMPLS and PCE protocols:
		=09

			1.	A single PCE computing both the path and wavelength=20
			2.	Two distinct PCEs, where one computes the path, and a different =
PCE computes the wavelength assignment=20
			3.	A PCE computes the path and wavelength assignment is accomplished =
in a distributed fashion via signaling (e.g., using label set objects)=20

			    Do we really need all three models?
		=09
			(c) G.709 includes the Optical Multiplex Section and Optical =
Channels.  RFC4238 was aimed at GMPLS extensions for G.709  (Optical =
Transport Network) control.  Weren't we finished with all this optical =
stuff years ago?
		=09
			I'd like to think the draft answers some of these questions.  I also =
think that network element models and the process models are important =
enough to warrant this separate framework document.  Your opinions are =
solicited.
		=09
			Regards
		=09
			Greg B.
		=09
			--=20
			=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
			Dr Greg Bernstein, Grotto Networking (510) 573-2237
		=09
			   =20


	--=20
	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
	Dr Greg Bernstein, Grotto Networking (510) 573-2237
=09


------_=_NextPart_001_01C80428.8A87C582
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125193711-01102007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Greg,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125193711-01102007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Greg Bernstein=20
  [mailto:gregb@grotto-networking.com] <BR><B>Sent:</B> venerd=EC 28 =
settembre=20
  2007 21.47<BR><B>To:</B> Giovanni Martinelli (giomarti)<BR><B>Cc:</B> =
ccamp;=20
  pce@ietf.org<BR><B>Subject:</B> Re: [Pce] Some key issues with =
Wavelength=20
  Switched Optical Networks...<BR></FONT><BR></DIV>
  <DIV></DIV>Hi Giovanni, thanks for the close read.&nbsp; Looks like =
you caught=20
  some problems with the text.&nbsp; See below for =
comments.<BR><BR>Giovanni=20
  Martinelli (giomarti) wrote:=20
  <BLOCKQUOTE=20
  =
cite=3Dmid:1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisc=
o.com=20
  type=3D"cite">
    <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>Hi=20
Greg,</FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">Sorry for the=20
    delay in replying. I'm working on this topic since a while so yes, =
it's=20
    interesting. Before going on specific issue I would have some=20
    question/clarification regarding the draft itself. =
</FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>* =
Within Abstract=20
    and the following.</FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>You =
don't talk about=20
    Optical Cross Connects (OXC) is something missing or understated=20
    somewhere?</FONT></DIV></BLOCKQUOTE>
  <DIV>--&gt;Whoops.&nbsp; We were trying to find a more general term to =
include=20
  both ROADM (usually a highly asymmetric fabric) and an OXC (a =
completely=20
  symmetric fabric, e.g., any ingress to any egress), but we seemed to =
have gone=20
  with using the ROADM terminology to include both cases.&nbsp; Talked =
with some=20
  equipment makers that planned/make "switches" that seemed to =
incorporate both=20
  so we made sure the model could deal with both sparse and dense =
potential=20
  connectivity. Diego had some terminology ideas but lately his e-mails =
have=20
  been bouncing back to me.&nbsp; Any suggestions are appreciated, but =
we are=20
  including both ROADM and OXCs.<SPAN class=3D125193711-01102007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>My doubt was coming from the ROADM definition in section 2 and =
picture=20
used later on the draft. At&nbsp; least in my understanding the OXC is a =
general=20
case for ROADM (sort of multi-degree ROADM) but ok, it's a matter of=20
terminology.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT><BR>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE=20
  =
cite=3Dmid:1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisc=
o.com=20
  type=3D"cite">
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">* Section 3.1=20
    where you state: </FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">"A fixed=20
    mapping between the </FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" =
size=3D2>GMPLS label space=20
    and these ITU-T WDM grids as proposed in [Otani] "</FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>Does =
it implies a=20
    sort of network level label space? How relate with usual local label =

    significance?</FONT></DIV></BLOCKQUOTE>
  <DIV>--&gt; This mapping gives a mapping between labels and=20
  wavelengths/lambda, just like in the SONET/SDH case we mapped the =
ITU-T G.707=20
  "S, U, K, L, M " identification of SDH time slots to a label format in =
RFC4606=20
  and again this was done in RFC4328 to map G.709 digital wrapper time =
slot=20
  identification into a technology specific label format.&nbsp; In =
RFC3471 for=20
  lambda switching we just get a 32 bit integer with no meaning =
attached. Every=20
  network and every node could potentially map labels to lambdas in a =
different=20
  way. In [Otani] they are following the RFC4606 and RFC4328 lead and =
using the=20
  ITU-T DWDM and CWDM lambda grid standards to give a fixed association =
between=20
  labels and lambdas just like between labels and TDM time slots in the =
SDH/ODU=20
  case.<BR><BR>This doesn't change the local significance of labels. In =
the=20
  wavelength switched optical case that is influenced by the presence or =
absence=20
  of wavelength converters.<SPAN class=3D125193711-01102007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Ok. Local significance&nbsp; but global semantic (as pointed =
out by=20
Adrian in a previous mail).</FONT>&nbsp;</SPAN><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE=20
  =
cite=3Dmid:1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisc=
o.com=20
  type=3D"cite">
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">* Section 3.4=20
    Wavelength Converters </FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" =
size=3D2>"Current or=20
    envisioned contexts for wavelength converters are : =
..."</FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" =
size=3D2>Could we&nbsp;<SPAN=20
    class=3D312013122-27092007>think to </SPAN>a description/model for =
wavelength=20
    converter that is technology agnostic?&nbsp;<SPAN=20
    class=3D312013122-27092007>S</SPAN><SPAN =
class=3D312013122-27092007>imply=20
    s</SPAN>omething like: full conversion capability, partial =
conversion=20
    capability with some constrains, and may be=20
  others.</FONT></DIV></BLOCKQUOTE>--&gt; The difference, between the =
all=20
  optical techniques and the OEO based techniques makes that =
difficult.<BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisc=
o.com=20
  type=3D"cite">
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">* Section 3.4.=20
    the following: </FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">"4. Wavelength=20
    converters that are O-E-O based will have a restriction =
</FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">based on the=20
    modulation format and transmission speed" </FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>Not =
clear to me the=20
    type of restriction here when OEO happens... probably I'm missing =
what you=20
    mean here.</FONT></DIV></BLOCKQUOTE>
  <DIV>--&gt; For example a typical O-E-O based wavelength converter =
would be=20
  build around a 3R regenerator with a tunable laser. A 3R regenerator =
cares=20
  about the modulation type say NRZ or RZ (and which flavor), and the =
symbol=20
  rate since its also doing retiming. An all optical wavelength =
converter will=20
  be fairly independent of these issues (except when we look at =
impairment=20
  factors). Hence the OEO wavelength is going to be more signal specific =
than=20
  the all optical.<SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>ok&nbsp;more clear now, although it would be nice having&nbsp;a =
general=20
model as you marked&nbsp; with TBD.</FONT>&nbsp;</SPAN><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE=20
  =
cite=3Dmid:1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisc=
o.com=20
  type=3D"cite">
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>* =
Section 4.1 when=20
    you talk about Lightpath temporal characteristics:</FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">"Lightpath=20
    connection duration has typically been thought of as =
</FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT size=3D2><FONT face=3D"Courier =
New">approximately=20
    three time frames: " </FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>and =
the following=20
    you define: dynamics, pseudo-static, static.</FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" size=3D2>Why =
there=92s a need=20
    of this classification? When you us Short/long is compared to=20
    what?</FONT></DIV></BLOCKQUOTE>
  <DIV>--&gt; In most of the research literature and in optimization =
practice=20
  different techniques are typically used in the dynamic versus static =
(or=20
  psuedo static cases).&nbsp; In MPLS there is minimum interference =
routing=20
  optimization techniques for the dynamic case. For the static case I =
could=20
  apply multi-commodity flow optimization techniques to a batch of=20
  connections.&nbsp; In the RWA literature there is a similar=20
  differentiation.&nbsp; Exactly what information could be sent to help =
PCE=20
  differentiate I'm not sure. In the case of static, batch optimization =
we can=20
  just use the existing concurrent optimization hooks in PCE. For an =
individual=20
  lightpath request it seemed that it would be helpful to know how long =
the=20
  connection would last so we'd know how much computational effort we =
might want=20
  to put into optimize it.<SPAN class=3D125193711-01102007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D125193711-01102007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>ok, clear. I still have doubt about quantifiers but fine for =
the=20
moment.</FONT></SPAN></DIV>
<DIV><SPAN class=3D125193711-01102007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D125193711-01102007><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D125193711-01102007><FONT face=3DArial color=3D#0000ff =

size=3D2>Giovanni</FONT></SPAN></DIV>
<DIV dir=3Dltr><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE=20
  =
cite=3Dmid:1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisc=
o.com=20
  type=3D"cite">
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D312013122-27092007><FONT=20
    face=3D"Courier New" size=3D2>minor typo on your mail below: point =
(c) rfc4328=20
    (not 4238) right?</FONT></SPAN></DIV></BLOCKQUOTE>--&gt; Yes.&nbsp; =
The G.709=20
  signaling extensions RFC.<BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:1F2FBF50FB955441A11316BAE835CED4042D142B@xmb-ams-338.emea.cisc=
o.com=20
  type=3D"cite">
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New" =
size=3D2>Thanks,</FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3D"Courier New"=20
size=3D2>Giovanni</FONT></DIV>
    <P><FONT face=3DArial size=3D2><BR></FONT>&nbsp;</P>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
rgb(0,0,255) 2px solid; MARGIN-RIGHT: 0px">
      <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
      <HR tabIndex=3D-1>
      <FONT face=3DTahoma size=3D2><B>From:</B> Greg Bernstein [<A=20
      class=3Dmoz-txt-link-freetext=20
      =
href=3D"mailto:gregb@grotto-networking.com">mailto:gregb@grotto-networkin=
g.com</A>]=20
      <BR><B>Sent:</B> gioved=EC 27 settembre 2007 1.42<BR><B>To:</B> =
ccamp; <A=20
      class=3Dmoz-txt-link-abbreviated=20
      href=3D"mailto:pce@ietf.org">pce@ietf.org</A><BR><B>Subject:</B> =
[Pce] Some=20
      key issues with Wavelength Switched Optical=20
      Networks...<BR></FONT><BR></DIV>Hi folks, I haven't seen too many =
comments=20
      on our draft "Framework for GMPLS and PCE Control of Wavelength =
Switched=20
      Optical Networks" ( <A=20
      =
href=3D"http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelen=
gth-switched-01.txt"=20
      =
moz-do-not-send=3D"true">http://www.ietf.org/internet-drafts/draft-bernst=
ein-ccamp-wavelength-switched-01.txt</A>).=20
      So I figured I'd point out some potentially controversial issues =
that the=20
      draft brings up. <BR><BR>(a) The draft brings up models for the =
following=20
      WDM network elements:<BR>
      <OL>
        <LI>WDM links=20
        <LI>Optical transmitters<BR>
        <LI>Wavelength Converters and OEO regenerators=20
        <LI>ROADMs, FOADMs, optical splitters and combiners.=20
      </LI></OL>&nbsp;&nbsp;&nbsp; For items (3) and (4) we are taking =
the=20
      modeling lead rather than some other SDO.&nbsp; And for ROADMs, in =

      particular, we going beyond the classic ITU-T "fabric" model =
(M.3100)=20
      which has been the mainstay of any connection oriented switch =
(TDM, ATM,=20
      MPLS).<BR><BR>(b) The draft brings up three (not one, not two, but =
three)=20
      different computational models for RWA which can impact GMPLS and =
PCE=20
      protocols:<BR>
      <OL>
        <LI>A single PCE computing both the path and wavelength=20
        <LI>Two distinct PCEs, where one computes the path, and a =
different PCE=20
        computes the wavelength assignment=20
        <LI>A PCE computes the path and wavelength assignment is =
accomplished in=20
        a distributed fashion via signaling (e.g., using label set =
objects)=20
      </LI></OL>&nbsp;&nbsp;&nbsp; Do we really need all three=20
      models?<BR><BR>(c) G.709 includes the Optical Multiplex Section =
and=20
      Optical Channels.&nbsp; RFC4238 was aimed at GMPLS extensions for=20
      G.709&nbsp; (Optical Transport Network) control.&nbsp; Weren't we =
finished=20
      with all this optical stuff years ago?<BR><BR>I'd like to think =
the draft=20
      answers some of these questions.&nbsp; I also think that network =
element=20
      models and the process models are important enough to warrant this =

      separate framework document.&nbsp; Your opinions are=20
      solicited.<BR><BR>Regards<BR><BR>Greg B.<BR><PRE =
class=3Dmoz-signature cols=3D"72">--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

    </PRE></BLOCKQUOTE></BLOCKQUOTE><BR><PRE class=3Dmoz-signature =
cols=3D"72">--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</PRE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C80428.8A87C582--



--===============2105766413==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============2105766413==--





From pce-bounces@lists.ietf.org Mon Oct 01 11:24:35 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IcN89-00033r-IZ; Mon, 01 Oct 2007 11:24:21 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IcN2u-0008IM-1j
	for pce-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 11:18:56 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IcN2t-0008Gl-O0 for pce@ietf.org; Mon, 01 Oct 2007 11:18:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IcN0B-0005sF-4G
	for pce@ietf.org; Mon, 01 Oct 2007 11:16:07 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcMzz-0003fB-RK
	for pce@ietf.org; Mon, 01 Oct 2007 11:16:02 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	45F7120452; Mon,  1 Oct 2007 17:15:45 +0200 (CEST)
X-AuditID: c1b4fb3e-af032bb0000007e1-30-47010f214aee
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	1FEE0200B9; Mon,  1 Oct 2007 17:15:45 +0200 (CEST)
Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 1 Oct 2007 17:15:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Pce] Some key issues with Wavelength Switched Optical Networks...
Date: Mon, 1 Oct 2007 17:16:08 +0200
Message-ID: <0428AC48A879ED46A94F39D5665DF684B2BDD4@esealmw110.eemea.ericsson.se>
In-Reply-To: <46FD7589.10505@grotto-networking.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pce] Some key issues with Wavelength Switched Optical
	Networks...
Thread-Index: AcgCGPrm079Irid9SsOzH8bH1pbmZQCI4MAw
From: "Diego Caviglia" <diego.caviglia@ericsson.com>
To: "Greg Bernstein" <gregb@grotto-networking.com>,
	"Igor Bryskin" <IBryskin@advaoptical.com>
X-OriginalArrivalTime: 01 Oct 2007 15:15:44.0731 (UTC)
	FILETIME=[F0125AB0:01C8043D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75
X-TMDA-Confirmed: Mon, 01 Oct 2007 11:18:55 -0400
X-Mailman-Approved-At: Mon, 01 Oct 2007 11:24:20 -0400
Cc: ccamp <ccamp@ops.ietf.org>, pce@ietf.org
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0071603008=="
Errors-To: pce-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============0071603008==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8043D.F00BEB88"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8043D.F00BEB88
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Igor hi Greg,

                      I think this is a very interesting discussion. =20

=20

IMHO the point Igor raised is on the boundary between network planning =
and circuit provisioning I mean the decision to have a node with/without =
conversion capability is a planning decision, likely dependent by a =
given traffic forecast and a physical topology.  Moreover the same =
consideration applies for 3R capabilities I mean is possible that an LSP =
needs 3R due to optical impairments.

=20

A possible solution to say that loopback are not allowed and thus if an =
LSP for some reason needs a loopback the PCE must return an error.  This =
information can be used to improve the wavelength conversion/3R =
capability of the network e.g. planning the deployment of more =
wavelength converter.  The other solution is to allow loopback. =20

=20

Best Regards


Diego

=20

 =20

=20

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On =
Behalf Of Greg Bernstein
Sent: venerd=EC 28 settembre 2007 23.44
To: Igor Bryskin
Cc: ccamp; pce@ietf.org
Subject: Re: [Pce] Some key issues with Wavelength Switched Optical =
Networks...

=20

Very good catch Igor. See in line.

Igor Bryskin wrote:=20

--snip--=20






=20

2. Considering wavelength conversion inevitably brings to the problem of =
looped paths, which is a completely new ball game in path computation, =
and I am surprised that the issue was never mentioned in the draft.

--> How is this different from the "looping" that can occur with a TDM =
multiplexer in a drop and continue mode?  Also in these two circuit =
cases (TDM, and optical) do we have the same danger as in the packet =
case where looping traffic can greatly degrade other flows.  Was there =
some general looping concerns already published for GMPLS with respect =
to circuits? =20

=20

IB>> There is a profound difference. I am not talking here about =
accidental looping, rather about deliberate looping: if some nodes can =
perform wavelength conversion while others can not, then you will want =
to route the connection to one or several conversion points and after =
that get it back on the main path. In other words you will deliberately =
request, say, a PCE to produce looped path, and then GMPLS RSVP-TE to =
signal looped path, which is completely out of normal paradigm of work =
for both PCE and RSVP.

--> I thought you were worried about accidental loops.  I didn't even =
consider what you are talking about "looping", but would RSVP processing =
get fouled up? It sure looks like a loop at the "node" level.=20
In the ERO the "node" subobject (IP4, IP6, AS) could definitely be =
repeated, but with a different "Label ERO" subobject appended. This is =
definitely something somebody would not to in the MPLS or TDM case.  =
I'll be sure to add it as an important difference in the next revision. =
Thanks!



=20

Cheers,=20

Igor

=20

________________________________

--snip--



--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
=20

------_=_NextPart_001_01C8043D.F00BEB88
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Igor hi =
Greg,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 I think this is a
very interesting discussion. =A0<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>IMHO the point Igor raised is on =
the
boundary between network planning and circuit provisioning I mean the =
decision to
have a node with/without conversion capability is a planning decision, =
likely
dependent by a given traffic forecast and a physical topology. =
=A0Moreover the
same consideration applies for 3R capabilities I mean is possible that =
an LSP
needs 3R due to optical impairments.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A possible solution to say that =
loopback
are not allowed and thus if an LSP for some reason needs a loopback the =
PCE must
return an error. =A0This information can be used to improve the =
wavelength conversion/3R
capability of the network e.g. planning the deployment of more =
wavelength converter.=A0
The other solution is to allow loopback.=A0 =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Best =
Regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><br>
Diego<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=A0=A0<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> owner-ccamp@ops.ietf.org =
[mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Greg Bernstein<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> venerd=EC 28 =
settembre 2007
23.44<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Igor Bryskin<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> ccamp; =
pce@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: [Pce] Some =
key issues
with Wavelength Switched Optical Networks...</span></font><font =
color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Very good catch Igor. See in line.<br>
<br>
Igor Bryskin wrote: <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:blue'><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"><!--[if gte mso 9]><xml>
  <u1:shapedefaults u2:ext=3D"edit" spidmax=3D"1026"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
  <u1:shapelayout u3:ext=3D"edit">
   <u1:idmap u3:ext=3D"edit" data=3D"1"/>
  </u1:shapelayout>
</xml><![endif]--></u1:SmartTagType>--snip--</span></font> =
<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><br>
<br>
<br>
<o:p></o:p></span></font></p>

<u1:p></u1:p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'><u5:p></u5:p><u5:p>&nbsp;</u5:p></sp=
an></font><u1:p></u1:p><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'>2. Considering wavelength =
conversion
inevitably brings to the problem of looped paths, which is a completely =
new ball
game in path computation, and I am surprised that the issue was never =
mentioned
in the draft.</span></font><u1:p></u1:p><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>--&gt; How is this different from the
&quot;looping&quot; that can occur with a TDM multiplexer in a drop and
continue mode?&nbsp; Also in these two circuit cases (TDM, and optical) =
do we
have the same danger as in the packet case where looping traffic can =
greatly
degrade other flows.&nbsp; Was there some general looping concerns =
already
published for GMPLS with respect to circuits?&nbsp; =
<o:p></o:p></span></font></p>

<u1:p></u1:p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'><u1:p>&nbsp;</u1:p></span></font><o:=
p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'>IB&gt;&gt; There is a profound =
difference.
I am not talking here about accidental looping, rather about deliberate
looping: if some nodes can perform wavelength conversion while others =
can not,
then you will want to route the connection to one or several conversion =
points
and after that get it back on the main path. In other words you will
deliberately request, say, a PCE to produce looped path, and then GMPLS =
RSVP-TE
to signal looped path, which is completely out of normal paradigm of =
work for
both PCE and RSVP.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>--&gt; I thought you were worried about =
accidental
loops.&nbsp; I didn't even consider what you are talking about
&quot;looping&quot;, but would RSVP processing get fouled up? It sure =
looks
like a loop at the &quot;node&quot; level. <br>
In the ERO the &quot;node&quot; subobject (IP4, IP6, AS) could =
definitely be
repeated, but with a different &quot;Label ERO&quot; subobject appended. =
This
is definitely something somebody would not to in the MPLS or TDM =
case.&nbsp;
I'll be sure to add it as an important difference in the next revision. =
Thanks!<br>
<br>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'><u1:p></u1:p><u1:p>&nbsp;</u1:p></sp=
an></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'>Cheers, =
<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'>Igor<u1:p></u1:p></span></font><o:p>=
</o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DArial><span =
style=3D'font-size:
12.0pt;font-family:Arial;color:blue'>&nbsp;<u5:p></u5:p></span></font><u1=
:p></u1:p><o:p></o:p></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

<hr size=3D3 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>--snip--<br>
<br>
<o:p></o:p></span></font></p>

<pre><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>-- <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Dr Greg Bernstein, Grotto Networking (510) =
573-2237<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre></div>

</div>

</body>

</html>

------_=_NextPart_001_01C8043D.F00BEB88--




--===============0071603008==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============0071603008==--






From pce-bounces@lists.ietf.org Tue Oct 02 03:26:32 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Icc8R-0001XQ-2w; Tue, 02 Oct 2007 03:25:39 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1Icc8P-0001XJ-OI
	for pce-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 03:25:37 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Icc8P-0001XB-Da
	for pce@ietf.org; Tue, 02 Oct 2007 03:25:37 -0400
Received: from smail5.alcatel.fr ([62.23.212.27])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icc8O-0002EC-Qn
	for pce@ietf.org; Tue, 02 Oct 2007 03:25:37 -0400
Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com
	[155.132.6.79])
	by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l927ONxG012890; 
	Tue, 2 Oct 2007 09:24:24 +0200
Received: from [172.27.205.178] ([172.27.205.178]) by
	FRVELSBHS07.ad2.ad.alcatel.com over TLS secured channel with
	Microsoft SMTPSVC(6.0.3790.2499); Tue, 2 Oct 2007 09:25:13 +0200
Message-ID: <4701F257.3040207@alcatel-lucent.fr>
Date: Tue, 02 Oct 2007 09:25:11 +0200
From: Martin Vigoureux <martin.vigoureux@alcatel-lucent.fr>
Organization: ALCATEL-LUCENT - CTO/R&I
User-Agent: Thunderbird 1.5.0.13 (Windows/20070809)
MIME-Version: 1.0
To: Greg Bernstein <gregb@grotto-networking.com>
Subject: Re: [Pce] Some key issues with Wavelength Switched Optical Networks...
References: <46FAEE2C.5040008@grotto-networking.com>	<DF7F96101FAF2A4E8856AAFB001E07C77756A1@atl-srv-mail.atl.advaoptical.com>
	<46FD51B9.9060909@grotto-networking.com>
In-Reply-To: <46FD51B9.9060909@grotto-networking.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 02 Oct 2007 07:25:13.0911 (UTC)
	FILETIME=[5F9AD470:01C804C5]
X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by smail5.alcatel.fr id
	l927ONxG012890
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: ccamp <ccamp@ops.ietf.org>, pce@ietf.org,
	Igor Bryskin <IBryskin@advaoptical.com>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hi Greg,

please see below

best regards,

martin

Greg Bernstein a =E9crit :
> Hi Igor, see comments below.
>=20
> Igor Bryskin wrote:
>>
>> Greg,
>>
>> =20
>>
>> I believe the draft is very useful.
>>
> --> Thanks!
>>
>> =20
>>
>> I have a couple of questions comments:
>>
>> =20
>>
>> 1. Section : 4.4. Traffic Grooming: Combining WSON and Higher Layer Ne=
twork=20
>>
>>    Optimization
>>
>> =20
>>
>> How the problem of grooming of higher layer network traffic over=20
>> optical trails is any different from the problem of traffic grooming=20
>> in TDM (e.g. VC12 over VC4)? I mean this is a general problem of=20
>> inter-layer relationship. I suggest moving all higher layer network=20
>> considerations out of scope of the draft and focusing on specifics of=20
>> the OCh layer.
>>
> --> Some of my co-authors agree with you on moving this section out. =20
> The reason that I put it in was that the optical "Traffic Grooming"=20
> problem has received a fair amount of attention in the research and=20
> general technical literature and is also a driver for the use of ROADMs=
=20
> (optical bypass).  I guess in general we've got the following=20
> inter-related problems: (a) virtual network topology design, (b) lower=20
> layer connection routing, (c) higher layer flow routing. In our case (b=
)=20
> is the RWA problem, which is fairly difficult in its own right. I guess=
=20
> I should look closely at the MLN/MRN work and see if a specific example=
=20
> that includes RWA is mentioned.  If so then I'd feel fine removing this=
=20
> section from the document.

Optical considerations are not explicitly covered in MRN/MLN documents
anymore, but we still talk a lot about virtual topologies in
multi-layer/region contexts.
Optical considerations were covered at the very beginning of these=20
documents, at the time they were called HPN (Hybrid Photonic Networks).
http://www.tools.ietf.org/html/draft-vigoureux-ccamp-gmpls-architecture-h=
pn-00



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Thu Oct 04 04:08:05 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IdLk1-0006ki-60; Thu, 04 Oct 2007 04:07:29 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IdLk0-0006kb-JU
	for pce-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 04:07:28 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IdLjy-0006br-7v
	for pce@ietf.org; Thu, 04 Oct 2007 04:07:26 -0400
Received: from smtp1.mail.atosorigin.com ([160.92.103.80]
	helo=wpwuee01s.mail.mercury.atosorigin.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdLjo-0001iE-4T
	for pce@ietf.org; Thu, 04 Oct 2007 04:07:16 -0400
Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1])
	by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id
	20AD3F4029 for <pce@ietf.org>; Thu,  4 Oct 2007 10:07:15 +0200 (CEST)
Received: from AOFR11476 (unknown [10.10.10.10])
	by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id
	927B0F4028 for <pce@ietf.org>; Thu,  4 Oct 2007 10:07:14 +0200 (CEST)
From: "Fabien VERHAEGHE" <fabien.verhaeghe@marben-products.com>
To: <pce@ietf.org>
Subject: TR: [Pce] TLV Format
Date: Thu, 4 Oct 2007 10:06:16 +0200
Message-ID: <001c01c8065d$70897180$18600337@AOFR11476>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001D_01C8066E.34124180"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acf2VwM43sRGcqKgQF6zmE6MnXLWAAASX58gA+6KuRA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 47d6e33caab9a47557c20591160ac87c
Cc: 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: fabien.verhaeghe@marben-products.com
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C8066E.34124180
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_001E_01C8066E.34124180"


------=_NextPart_001_001E_01C8066E.34124180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

I did not see any reply for this comment.=20

I seize the opportunity to clarify my opinion:

=20

I think TLV alignment statement must be a general rules for all TLVs of =
a
given object.

The draft then needs also to specify that the alignment padding bytes =
must
be included before

or after the value field.

=20

The Length field would carry the actual length of the value without =
padding
bytes due to alignment.

=20

Those statements seem important to me for the processing of unknown =
TLVs.=20

=20

With this general rules there is no need to specify that 2 unused bytes =
must
be added for 4 bytes length

value TLV such as The REQ-MISSING.

=20

Note that I=92m not sure why the draft proposed a 8 bytes alignment (Why =
not 4
bytes since in section 7.1

it is said that object length must always be a multiple of 4?).

=20

Does it make sense?

=20

Best regards

Fabien

=20

=20

  _____ =20

De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]=20
Envoy=E9 : vendredi 14 septembre 2007 09:45
=C0 : pce@ietf.org
Objet : [Pce] TLV Format

=20

Hi,

=20

I think there is a little problem with PCEP object TLV format.

=20

The main problem being that the general format of the TLVs is not =
described
(Type, length value length, 4 bytes alignment=85).

=20

Besides for existing TLVs we have:

=20

=20

=93The REQ-MISSING TLV is composed of 1 byte for the type,

1 byte specifying the number of bytes in the value field, 2 bytes

for an "Unused" field (the value of which MUST be set to 0), followed by

a fix length value field of 4 bytes specifying the request-id-number

that correspond to the missing request.=20

The REQ-MISSING TLV is padded to eight-byte alignment.

=20

TYPE: To be assigned by IANA

LENGTH: 4

VALUE: request-id-number that corresponds to the missing request=94

=20

I think the LENGTH field should be set to 6, the unused field 2 bytes =
being
part of the Value field. Otherwise

it means those 2 bytes are part of the TLV header and it should be said =
that
all TLVs will be formatted with

this 4 bytes header i.e. Type (1byte) =96 Value field Length (1byte) =96 =
Unused
field (2bytes) =96 Value field

Otherwise, there may be some problem when decoding a message with =
unknown
TLV.

=20

Besides I=92m not sure about the =93The REQ-MISSING TLV is padded to =
eight-byte
alignment.=94 statement.

Is it really needed?

=20

For the NO-PATH-VECTOR TLV we have

=20

=93The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

   specifying the number of bytes in the value field, followed by a fix

   length value field of 32-bits flags field used to report the

   reason(s) that led to unsuccessful path computation.

=20

   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.

=20

TYPE: To be assigned by IANA

=20

   LENGTH: 4

=20

   VALUE: 32-bits flags field=94

=20

In this case there is no Unused field 2 bytes.=20

I think it would be better to have the same format for all TLVs of all
object.

And again I=92m wondering if the LENGTH field should be set to 4 or 6?

=20

Can you please clarify this to me? Am I missing something?

=20

Thanks

Fabien

=20


------=_NextPart_001_001E_01C8066E.34124180
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dblue style=3D'word-wrap: =
break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I did not see =
any reply
for this comment. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I seize the =
opportunity
to clarify my opinion:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I think TLV =
alignment
statement must be a general rules for all TLVs of a given =
object.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The draft then =
needs also
to specify that the alignment padding bytes must be included =
before<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>or after the =
value field.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The Length field =
would
carry the actual length of the value without padding bytes due to =
alignment.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Those statements =
seem
important to me for the processing of unknown TLVs. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>With this =
general rules there
is no need to specify that 2 unused bytes must be added for 4 bytes =
length<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>value TLV such =
as The
REQ-MISSING.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Note that =
I&#8217;m not sure
why the draft proposed a 8 bytes alignment (Why not 4 bytes since in =
section 7.1<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>it is said that =
object
length must always be a multiple of 4?).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Does it make =
sense?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Best =
regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Fabien<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>De&nbsp;:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
<st1:PersonName
ProductID=3D"Fabien VERHAEGHE" w:st=3D"on">Fabien =
VERHAEGHE</st1:PersonName>
[mailto:fabien.verhaeghe@marben-products.com] <br>
<b><span style=3D'font-weight:bold'>Envoy=E9&nbsp;:</span></b> vendredi =
14
septembre 2007 09:45<br>
<b><span style=3D'font-weight:bold'>=C0&nbsp;:</span></b> =
pce@ietf.org<br>
<b><span style=3D'font-weight:bold'>Objet&nbsp;:</span></b> [Pce] TLV =
Format</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I think there is =
a little
problem with PCEP object TLV format.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The main problem =
being
that the general format of the TLVs is not described (Type, length value
length, 4 bytes alignment&#8230;).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Besides for =
existing TLVs
we have:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&#8220;The =
REQ-MISSING
TLV is composed of 1 byte for the type,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>1 byte =
specifying the
number of bytes in the value field, 2 bytes<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>for an =
&quot;Unused&quot;
field (the value of which MUST be set to 0), followed =
by<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>a fix length =
value field
of 4 bytes specifying the request-id-number<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>that correspond =
to the
missing request. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>The REQ-MISSING =
TLV is
padded to eight-byte alignment.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>TYPE: To be =
assigned by
IANA<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>LENGTH: =
4<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>VALUE: =
request-id-number
that corresponds to the missing =
request&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I think the =
LENGTH field
should be set to 6, the unused field 2 bytes being part of the Value =
field.
Otherwise<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>it means those 2 =
bytes
are part of the TLV header and it should be said that all TLVs will be
formatted with<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>this 4 bytes =
header i.e.
Type (1byte) &#8211; Value field Length (1byte) &#8211; Unused field =
(2bytes)
&#8211; Value field<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Otherwise, there =
may be
some problem when decoding a message with unknown =
TLV.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Besides =
I&#8217;m not
sure about the &#8220;The REQ-MISSING TLV is padded to eight-byte
alignment.&#8221; statement.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Is it really =
needed?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>For the =
NO-PATH-VECTOR
TLV we have<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&#8220;The =
NO-PATH-VECTOR
TLV is composed of 1 byte for the type, 1 =
byte<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; =
specifying
the number of bytes in the value field, followed by a =
fix<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; =
length value
field of 32-bits flags field used to report =
the<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; =
reason(s)
that led to unsuccessful path computation.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; The
NO-PATH-VECTOR TLV is padded to eight-byte =
alignment.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>TYPE: To be =
assigned by
IANA<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; =
LENGTH: 4<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp; =
VALUE:
32-bits flags field&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In this case =
there is no
Unused field 2 bytes. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I think it would =
be better
to have the same format for all TLVs of all =
object.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>And again =
I&#8217;m
wondering if the LENGTH field should be set to 4 or =
6?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Can you please =
clarify
this to me? Am I missing something?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Thanks<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Fabien<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_001_001E_01C8066E.34124180--

------=_NextPart_000_001D_01C8066E.34124180
Content-Type: text/plain;
	name="ATT00076.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00076.txt"

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

------=_NextPart_000_001D_01C8066E.34124180
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

------=_NextPart_000_001D_01C8066E.34124180--






From pce-bounces@lists.ietf.org Thu Oct 04 05:27:50 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IdMyB-0007F4-2G; Thu, 04 Oct 2007 05:26:11 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IdMy9-0007Ey-V4
	for pce-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 05:26:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IdMy9-00077c-Ht
	for pce@ietf.org; Thu, 04 Oct 2007 05:26:09 -0400
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdMy0-0007Y9-2D
	for pce@ietf.org; Thu, 04 Oct 2007 05:26:07 -0400
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 4 Oct 2007 11:25:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Pce] TLV Format
Date: Thu, 4 Oct 2007 11:25:41 +0200
Message-ID: <D109C8C97C15294495117745780657AE0873382E@ftrdmel1>
In-Reply-To: <001c01c8065d$70897180$18600337@AOFR11476>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pce] TLV Format
Thread-Index: Acf2VwM43sRGcqKgQF6zmE6MnXLWAAASX58gA+6KuRAAAr71cA==
References: <001c01c8065d$70897180$18600337@AOFR11476>
From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ftgroup.com>
To: <fabien.verhaeghe@marben-products.com>,
	<pce@ietf.org>
X-OriginalArrivalTime: 04 Oct 2007 09:25:43.0118 (UTC)
	FILETIME=[895FC6E0:01C80668]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2ef8a017d8070cfdc3108436d3b9538
Cc: 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1178934251=="
Errors-To: pce-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1178934251==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C80668.893454F9"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C80668.893454F9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Fabien
=20
Sorry for the late reply
=20
Please see inline,


________________________________

	De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]=20
	Envoy=E9 : jeudi 4 octobre 2007 10:06
	=C0 : pce@ietf.org
	Objet : TR: [Pce] TLV Format
=09
=09

	Hello,

	=20

	I did not see any reply for this comment.=20

	I seize the opportunity to clarify my opinion:

	=20

	I think TLV alignment statement must be a general rules for all TLVs of =
a given object.=20

	=20

	Definitely right. We are going to add a section on generic TLV =
encoding. All TLVs specificed in PCEP objects will have to follow this =
encoding.

	=20

	Here it is:

	=20

	=20

	7.1.1. PCEP Object TLVs

	=20

	A PCEP object may include a set of one or more optional TLV(s).
	A PCEP object TLV is comprised of 2 octets for the type, 2 octets =
specifying the TLV length,=20
	and a value field. The Length field defines the length of the value =
portion in octets.=20
	The TLV is padded to four-octet alignment; padding is not included in =
the Length field=20
	(so a three octet value would have a length of three, but the total =
size of the TLV would=20
	be eight octets).

	PCEP Object TLV types MUST be managed by IANA.

	Unrecognized TLVs MUST be ignored.

	=20

	=20

	Note that this is the encoding already used in RFC 3630 & 4420.

	=20

	=20

	=20

	The draft then needs also to specify that the alignment padding bytes =
must be included before

	or after the value field.=20

	=20

	 The Length field would carry the actual length of the value without =
padding bytes due to alignment.

	=20

	Those statements seem important to me for the processing of unknown =
TLVs.=20

	=20

	Sure

	=20

	With this general rules there is no need to specify that 2 unused bytes =
must be added for 4 bytes length

	value TLV such as The REQ-MISSING.

	=20

	Note that I'm not sure why the draft proposed a 8 bytes alignment (Why =
not 4 bytes since in section 7.1

	it is said that object length must always be a multiple of 4?).=20

	=20

	Yes this was a mistake. We are going to align TLV definitions to new =
section 7.1.1.

	=20

	Thanks for your comment.

	=20

	Regards,

	=20

	JL

	=20

	Does it make sense?

	=20

	Best regards

	Fabien

	=20

	=20

=09
________________________________


	De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]=20
	Envoy=E9 : vendredi 14 septembre 2007 09:45
	=C0 : pce@ietf.org
	Objet : [Pce] TLV Format

	=20

	Hi,

	=20

	I think there is a little problem with PCEP object TLV format.

	=20

	The main problem being that the general format of the TLVs is not =
described (Type, length value length, 4 bytes alignment...).

	=20

	Besides for existing TLVs we have:

	=20

	=20

	"The REQ-MISSING TLV is composed of 1 byte for the type,

	1 byte specifying the number of bytes in the value field, 2 bytes

	for an "Unused" field (the value of which MUST be set to 0), followed =
by

	a fix length value field of 4 bytes specifying the request-id-number

	that correspond to the missing request.=20

	The REQ-MISSING TLV is padded to eight-byte alignment.

	=20

	TYPE: To be assigned by IANA

	LENGTH: 4

	VALUE: request-id-number that corresponds to the missing request"

	=20

	I think the LENGTH field should be set to 6, the unused field 2 bytes =
being part of the Value field. Otherwise

	it means those 2 bytes are part of the TLV header and it should be said =
that all TLVs will be formatted with

	this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - =
Unused field (2bytes) - Value field

	Otherwise, there may be some problem when decoding a message with =
unknown TLV.

	=20

	Besides I'm not sure about the "The REQ-MISSING TLV is padded to =
eight-byte alignment." statement.

	Is it really needed?

	=20

	For the NO-PATH-VECTOR TLV we have

	=20

	"The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

	   specifying the number of bytes in the value field, followed by a fix

	   length value field of 32-bits flags field used to report the

	   reason(s) that led to unsuccessful path computation.

	=20

	   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.

	=20

	TYPE: To be assigned by IANA

	=20

	   LENGTH: 4

	=20

	   VALUE: 32-bits flags field"

	=20

	In this case there is no Unused field 2 bytes.=20

	I think it would be better to have the same format for all TLVs of all =
object.

	And again I'm wondering if the LENGTH field should be set to 4 or 6?

	=20

	Can you please clarify this to me? Am I missing something?

	=20

	Thanks

	Fabien

	=20


------_=_NextPart_001_01C80668.893454F9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DFR=20
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D747060509-04102007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Fabien</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D747060509-04102007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D747060509-04102007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Sorry for the late reply</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D747060509-04102007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D747060509-04102007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Please see inline,</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>De&nbsp;:</B> Fabien VERHAEGHE=20
  [mailto:fabien.verhaeghe@marben-products.com] =
<BR><B>Envoy=E9&nbsp;:</B> jeudi 4=20
  octobre 2007 10:06<BR><B>=C0&nbsp;:</B> =
pce@ietf.org<BR><B>Objet&nbsp;:</B> TR:=20
  [Pce] TLV Format<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Hello,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I did not =
see any=20
  reply for this comment. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I seize the =

  opportunity to clarify my opinion:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think TLV =
alignment=20
  statement must be a general rules for all TLVs of a given object.<FONT =

  color=3D#0000ff><SPAN=20
  class=3D747060509-04102007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><SPAN =

  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#ff0000><SPAN class=3D747060509-04102007>Definitely right. We =
are going to=20
  add a section on generic TLV encoding. All TLVs specificed in PCEP =
objects=20
  will have to follow this encoding.</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#ff0000><SPAN=20
  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#ff0000><SPAN class=3D747060509-04102007>Here it=20
  is:</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><SPAN =

  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><SPAN =

  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  face=3D"Courier New" color=3D#000000><SPAN =
class=3D747060509-04102007>7.1.1. PCEP=20
  Object TLVs</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  face=3D"Courier New"><SPAN=20
  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  face=3D"Courier New" color=3D#000000><SPAN =
class=3D747060509-04102007>A PCEP object=20
  may include a set of one or more optional TLV(s).<BR>A PCEP object TLV =
is=20
  comprised of 2 octets for the type, 2 octets specifying the TLV =
length,=20
  <BR>and a value field. The Length field defines the length of the =
value=20
  portion in octets. <BR>The TLV is padded to four-octet alignment; =
padding is=20
  not included in the Length field <BR>(so a three octet value would =
have a=20
  length of three, but the total size of the TLV would <BR>be eight=20
  octets).</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  face=3D"Courier New" color=3D#000000><SPAN =
class=3D747060509-04102007>PCEP Object=20
  TLV types MUST be managed by IANA.</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  face=3D"Courier New" color=3D#000000><SPAN =
class=3D747060509-04102007>Unrecognized=20
  TLVs MUST be ignored.</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  face=3D"Courier New" color=3D#000000><SPAN=20
  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><SPAN =

  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#ff0000><SPAN class=3D747060509-04102007>Note that this is the =
encoding=20
  already used in RFC 3630&nbsp;&amp; =
4420.</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT =
face=3DArial=20
  color=3D#0000ff><SPAN=20
  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#0000ff><SPAN=20
  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#0000ff><SPAN=20
  =
class=3D747060509-04102007>&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT><=
/P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The draft =
then needs=20
  also to specify that the alignment padding bytes must be included=20
  before<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">or after =
the value=20
  field.<FONT color=3D#0000ff><SPAN=20
  class=3D747060509-04102007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#0000ff><SPAN=20
  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The Length =
field=20
  would carry the actual length of the value without padding bytes due =
to=20
  alignment.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Those =
statements seem=20
  important to me for the processing of unknown TLVs.=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN=20
  class=3D747060509-04102007><FONT=20
  color=3D#ff0000>Sure</FONT></SPAN></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">With this =
general=20
  rules there is no need to specify that 2 unused bytes must be added =
for 4=20
  bytes length<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">value TLV =
such as The=20
  REQ-MISSING.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Note that =
I=92m not=20
  sure why the draft proposed a 8 bytes alignment (Why not 4 bytes since =
in=20
  section 7.1<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">it is said =
that=20
  object length must always be a multiple of 4?).<FONT =
color=3D#0000ff><SPAN=20
  class=3D747060509-04102007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT color=3Dnavy><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#0000ff><SPAN=20
  class=3D747060509-04102007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><FONT =

  color=3D#ff0000><SPAN class=3D747060509-04102007>Yes this&nbsp;was a =
mistake. We=20
  are going to align TLV definitions to new section=20
  7.1.1.</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><FONT =

  color=3D#ff0000><SPAN=20
  =
class=3D747060509-04102007></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><FONT =

  color=3D#ff0000><SPAN class=3D747060509-04102007>Thanks for your=20
  comment.</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><FONT =

  color=3D#ff0000><SPAN=20
  =
class=3D747060509-04102007></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><FONT =

  color=3D#ff0000><SPAN=20
  =
class=3D747060509-04102007>Regards,</SPAN></FONT></FONT></SPAN></FONT></P=
>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><FONT =

  color=3D#ff0000><SPAN=20
  =
class=3D747060509-04102007></SPAN></FONT></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><FONT =

  color=3D#ff0000><SPAN=20
  class=3D747060509-04102007>JL</SPAN></FONT></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Does it =
make=20
  sense?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Best=20
  regards<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Fabien<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">De&nbsp;:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  <st1:PersonName w:st=3D"on" ProductID=3D"Fabien VERHAEGHE">Fabien=20
  VERHAEGHE</st1:PersonName> =
[mailto:fabien.verhaeghe@marben-products.com]=20
  <BR><B><SPAN style=3D"FONT-WEIGHT: bold">Envoy=E9&nbsp;:</SPAN></B> =
vendredi 14=20
  septembre 2007 09:45<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">=C0&nbsp;:</SPAN></B>=20
  pce@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Objet&nbsp;:</SPAN></B>=20
  [Pce] TLV Format</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Hi,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think =
there is a=20
  little problem with PCEP object TLV =
format.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The main =
problem=20
  being that the general format of the TLVs is not described (Type, =
length value=20
  length, 4 bytes alignment=85).<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Besides for =
existing=20
  TLVs we have:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">=93The =
REQ-MISSING TLV=20
  is composed of 1 byte for the type,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">1 byte =
specifying the=20
  number of bytes in the value field, 2 =
bytes<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">for an =
"Unused" field=20
  (the value of which MUST be set to 0), followed=20
by<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">a fix =
length value=20
  field of 4 bytes specifying the =
request-id-number<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">that =
correspond to=20
  the missing request. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The =
REQ-MISSING TLV=20
  is padded to eight-byte alignment.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">TYPE: To be =
assigned=20
  by IANA<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">LENGTH:=20
  4<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">VALUE:=20
  request-id-number that corresponds to the missing=20
  request=94<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think the =
LENGTH=20
  field should be set to 6, the unused field 2 bytes being part of the =
Value=20
  field. Otherwise<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">it means =
those 2=20
  bytes are part of the TLV header and it should be said that all TLVs =
will be=20
  formatted with<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">this 4 =
bytes header=20
  i.e. Type (1byte) =96 Value field Length (1byte) =96 Unused field =
(2bytes) =96 Value=20
  field<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Otherwise, =
there may=20
  be some problem when decoding a message with unknown=20
  TLV.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Besides =
I=92m not sure=20
  about the =93The REQ-MISSING TLV is padded to eight-byte alignment.=94 =

  statement.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Is it =
really=20
  needed?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">For the=20
  NO-PATH-VECTOR TLV we have<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">=93The =
NO-PATH-VECTOR=20
  TLV is composed of 1 byte for the type, 1 =
byte<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp;=20
  specifying the number of bytes in the value field, followed by a=20
  fix<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp; length=20
  value field of 32-bits flags field used to report=20
  the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp;=20
  reason(s) that led to unsuccessful path=20
  computation.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp; The=20
  NO-PATH-VECTOR TLV is padded to eight-byte=20
  alignment.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">TYPE: To be =
assigned=20
  by IANA<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp; LENGTH:=20
  4<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp; VALUE:=20
  32-bits flags field=94<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In this =
case there is=20
  no Unused field 2 bytes. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think it =
would be=20
  better to have the same format for all TLVs of all=20
  object.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">And again =
I=92m=20
  wondering if the LENGTH field should be set to 4 or=20
  6?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Can you =
please=20
  clarify this to me? Am I missing =
something?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Fabien<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></DIV></DIV></BLOCKQUOTE>=
</BODY></HTML>

------_=_NextPart_001_01C80668.893454F9--



--===============1178934251==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============1178934251==--





From pce-bounces@lists.ietf.org Thu Oct 04 08:51:40 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IdQA3-0001TM-1H; Thu, 04 Oct 2007 08:50:39 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IdQA2-0001TG-Cg
	for pce-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 08:50:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IdQA2-0001SL-2K
	for pce@ietf.org; Thu, 04 Oct 2007 08:50:38 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdQ9v-00079E-Gw
	for pce@ietf.org; Thu, 04 Oct 2007 08:50:38 -0400
Received: from [88.96.235.138] (helo=cortex.aria-networks.com)
	by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IdQ9u-00048o-Di
	for pce@ietf.org; Thu, 04 Oct 2007 12:50:30 +0000
Received: from your029b8cecfe ([88.96.235.138] RDNS failed) by
	cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 4 Oct 2007 13:50:29 +0100
Message-ID: <005401c80685$2068b850$5102010a@your029b8cecfe>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ftgroup.com>,
	<fabien.verhaeghe@marben-products.com>, <pce@ietf.org>
References: <001c01c8065d$70897180$18600337@AOFR11476>
	<D109C8C97C15294495117745780657AE0873382E@ftrdmel1>
Subject: Re: [Pce] TLV Format
Date: Thu, 4 Oct 2007 13:50:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 04 Oct 2007 12:50:29.0999 (UTC)
	FILETIME=[24ED07F0:01C80685]
X-Originating-Heisenberg-IP: [88.96.235.138]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4515df9441674711565101d9d5c4f63f
Cc: 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hi,

Did you see the question about padding and lengths on the CCAMP and OSPF 
lists?

It might be worth getting this explained in the PCEP I-D, as well. The 
questions are:

When an object contains a TLV with padding (so the TLV length field does not 
include the length of the padding) what is the value of the length field in 
the object?

When a TLV contains multiple TLVs with padding, what is the value of the 
length field in the object?

When a TLV contains sub-TLVs with padding, what is the value of the length 
field in the TLV?

These three questions seem to have well-known and "obvious" answers for 
other protocols, but are not written down. Let's write them down for PCEP.

Cheers,
Adrian

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ftgroup.com>
To: <fabien.verhaeghe@marben-products.com>; <pce@ietf.org>
Sent: Thursday, October 04, 2007 10:25 AM
Subject: RE: [Pce] TLV Format


Hi Fabien

Sorry for the late reply

Please see inline,


________________________________

De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]
Envoyé : jeudi 4 octobre 2007 10:06
À : pce@ietf.org
Objet : TR: [Pce] TLV Format



Hello,



I did not see any reply for this comment.

I seize the opportunity to clarify my opinion:



I think TLV alignment statement must be a general rules for all TLVs of a 
given object.



Definitely right. We are going to add a section on generic TLV encoding. All 
TLVs specificed in PCEP objects will have to follow this encoding.



Here it is:





7.1.1. PCEP Object TLVs



A PCEP object may include a set of one or more optional TLV(s).
A PCEP object TLV is comprised of 2 octets for the type, 2 octets specifying 
the TLV length,
and a value field. The Length field defines the length of the value portion 
in octets.
The TLV is padded to four-octet alignment; padding is not included in the 
Length field
(so a three octet value would have a length of three, but the total size of 
the TLV would
be eight octets).

PCEP Object TLV types MUST be managed by IANA.

Unrecognized TLVs MUST be ignored.





Note that this is the encoding already used in RFC 3630 & 4420.







The draft then needs also to specify that the alignment padding bytes must 
be included before

or after the value field.



The Length field would carry the actual length of the value without padding 
bytes due to alignment.



Those statements seem important to me for the processing of unknown TLVs.



Sure



With this general rules there is no need to specify that 2 unused bytes must 
be added for 4 bytes length

value TLV such as The REQ-MISSING.



Note that I'm not sure why the draft proposed a 8 bytes alignment (Why not 4 
bytes since in section 7.1

it is said that object length must always be a multiple of 4?).



Yes this was a mistake. We are going to align TLV definitions to new section 
7.1.1.



Thanks for your comment.



Regards,



JL



Does it make sense?



Best regards

Fabien






________________________________


De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]
Envoyé : vendredi 14 septembre 2007 09:45
À : pce@ietf.org
Objet : [Pce] TLV Format



Hi,



I think there is a little problem with PCEP object TLV format.



The main problem being that the general format of the TLVs is not described 
(Type, length value length, 4 bytes alignment...).



Besides for existing TLVs we have:





"The REQ-MISSING TLV is composed of 1 byte for the type,

1 byte specifying the number of bytes in the value field, 2 bytes

for an "Unused" field (the value of which MUST be set to 0), followed by

a fix length value field of 4 bytes specifying the request-id-number

that correspond to the missing request.

The REQ-MISSING TLV is padded to eight-byte alignment.



TYPE: To be assigned by IANA

LENGTH: 4

VALUE: request-id-number that corresponds to the missing request"



I think the LENGTH field should be set to 6, the unused field 2 bytes being 
part of the Value field. Otherwise

it means those 2 bytes are part of the TLV header and it should be said that 
all TLVs will be formatted with

this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) - Unused 
field (2bytes) - Value field

Otherwise, there may be some problem when decoding a message with unknown 
TLV.



Besides I'm not sure about the "The REQ-MISSING TLV is padded to eight-byte 
alignment." statement.

Is it really needed?



For the NO-PATH-VECTOR TLV we have



"The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte

   specifying the number of bytes in the value field, followed by a fix

   length value field of 32-bits flags field used to report the

   reason(s) that led to unsuccessful path computation.



   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.



TYPE: To be assigned by IANA



   LENGTH: 4



   VALUE: 32-bits flags field"



In this case there is no Unused field 2 bytes.

I think it would be better to have the same format for all TLVs of all 
object.

And again I'm wondering if the LENGTH field should be set to 4 or 6?



Can you please clarify this to me? Am I missing something?



Thanks

Fabien






--------------------------------------------------------------------------------


> _______________________________________________
> Pce mailing list
> Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
> 




_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Thu Oct 04 10:13:51 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IdRS7-0004oA-NU; Thu, 04 Oct 2007 10:13:23 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IdRS6-0004lZ-Nf
	for pce-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 10:13:22 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IdRS6-0004kG-7y
	for pce@ietf.org; Thu, 04 Oct 2007 10:13:22 -0400
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdRS4-0000Fh-Qp
	for pce@ietf.org; Thu, 04 Oct 2007 10:13:22 -0400
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 4 Oct 2007 16:13:01 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Pce] TLV Format
Date: Thu, 4 Oct 2007 16:13:05 +0200
Message-ID: <D109C8C97C15294495117745780657AE08733D16@ftrdmel1>
In-Reply-To: <005401c80685$2068b850$5102010a@your029b8cecfe>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pce] TLV Format
Thread-Index: AcgGhSY3Qlye40xpT1uaPtZrFJbkcgACoIBw
References: <001c01c8065d$70897180$18600337@AOFR11476>
	<D109C8C97C15294495117745780657AE0873382E@ftrdmel1>
	<005401c80685$2068b850$5102010a@your029b8cecfe>
From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ftgroup.com>
To: <adrian@olddog.co.uk>, <fabien.verhaeghe@marben-products.com>,
	<pce@ietf.org>
X-OriginalArrivalTime: 04 Oct 2007 14:13:01.0120 (UTC)
	FILETIME=[AC062400:01C80690]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05
Cc: 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hi Adrian,

OK, good point.
We will cover these three questions in rev 09.

Thanks,

JL

> -----Message d'origine-----
> De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20
> Envoy=E9 : jeudi 4 octobre 2007 14:50
> =C0 : LE ROUX Jean-Louis RD-CORE-LAN;=20
> fabien.verhaeghe@marben-products.com; pce@ietf.org
> Objet : Re: [Pce] TLV Format
>=20
> Hi,
>=20
> Did you see the question about padding and lengths on the=20
> CCAMP and OSPF lists?
>=20
> It might be worth getting this explained in the PCEP I-D, as=20
> well. The questions are:
>=20
> When an object contains a TLV with padding (so the TLV length=20
> field does not include the length of the padding) what is the=20
> value of the length field in the object?
>=20
> When a TLV contains multiple TLVs with padding, what is the=20
> value of the length field in the object?
>=20
> When a TLV contains sub-TLVs with padding, what is the value=20
> of the length field in the TLV?
>=20
> These three questions seem to have well-known and "obvious"=20
> answers for other protocols, but are not written down. Let's=20
> write them down for PCEP.
>=20
> Cheers,
> Adrian
>=20
> ----- Original Message -----
> From: "LE ROUX Jean-Louis RD-CORE-LAN"=20
> <jeanlouis.leroux@orange-ftgroup.com>
> To: <fabien.verhaeghe@marben-products.com>; <pce@ietf.org>
> Sent: Thursday, October 04, 2007 10:25 AM
> Subject: RE: [Pce] TLV Format
>=20
>=20
> Hi Fabien
>=20
> Sorry for the late reply
>=20
> Please see inline,
>=20
>=20
> ________________________________
>=20
> De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]
> Envoy=E9 : jeudi 4 octobre 2007 10:06
> =C0 : pce@ietf.org
> Objet : TR: [Pce] TLV Format
>=20
>=20
>=20
> Hello,
>=20
>=20
>=20
> I did not see any reply for this comment.
>=20
> I seize the opportunity to clarify my opinion:
>=20
>=20
>=20
> I think TLV alignment statement must be a general rules for=20
> all TLVs of a=20
> given object.
>=20
>=20
>=20
> Definitely right. We are going to add a section on generic=20
> TLV encoding. All=20
> TLVs specificed in PCEP objects will have to follow this encoding.
>=20
>=20
>=20
> Here it is:
>=20
>=20
>=20
>=20
>=20
> 7.1.1. PCEP Object TLVs
>=20
>=20
>=20
> A PCEP object may include a set of one or more optional TLV(s).
> A PCEP object TLV is comprised of 2 octets for the type, 2=20
> octets specifying=20
> the TLV length,
> and a value field. The Length field defines the length of the=20
> value portion=20
> in octets.
> The TLV is padded to four-octet alignment; padding is not=20
> included in the=20
> Length field
> (so a three octet value would have a length of three, but the=20
> total size of=20
> the TLV would
> be eight octets).
>=20
> PCEP Object TLV types MUST be managed by IANA.
>=20
> Unrecognized TLVs MUST be ignored.
>=20
>=20
>=20
>=20
>=20
> Note that this is the encoding already used in RFC 3630 & 4420.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> The draft then needs also to specify that the alignment=20
> padding bytes must=20
> be included before
>=20
> or after the value field.
>=20
>=20
>=20
> The Length field would carry the actual length of the value=20
> without padding=20
> bytes due to alignment.
>=20
>=20
>=20
> Those statements seem important to me for the processing of=20
> unknown TLVs.
>=20
>=20
>=20
> Sure
>=20
>=20
>=20
> With this general rules there is no need to specify that 2=20
> unused bytes must=20
> be added for 4 bytes length
>=20
> value TLV such as The REQ-MISSING.
>=20
>=20
>=20
> Note that I'm not sure why the draft proposed a 8 bytes=20
> alignment (Why not 4=20
> bytes since in section 7.1
>=20
> it is said that object length must always be a multiple of 4?).
>=20
>=20
>=20
> Yes this was a mistake. We are going to align TLV definitions=20
> to new section=20
> 7.1.1.
>=20
>=20
>=20
> Thanks for your comment.
>=20
>=20
>=20
> Regards,
>=20
>=20
>=20
> JL
>=20
>=20
>=20
> Does it make sense?
>=20
>=20
>=20
> Best regards
>=20
> Fabien
>=20
>=20
>=20
>=20
>=20
>=20
> ________________________________
>=20
>=20
> De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]
> Envoy=E9 : vendredi 14 septembre 2007 09:45
> =C0 : pce@ietf.org
> Objet : [Pce] TLV Format
>=20
>=20
>=20
> Hi,
>=20
>=20
>=20
> I think there is a little problem with PCEP object TLV format.
>=20
>=20
>=20
> The main problem being that the general format of the TLVs is=20
> not described=20
> (Type, length value length, 4 bytes alignment...).
>=20
>=20
>=20
> Besides for existing TLVs we have:
>=20
>=20
>=20
>=20
>=20
> "The REQ-MISSING TLV is composed of 1 byte for the type,
>=20
> 1 byte specifying the number of bytes in the value field, 2 bytes
>=20
> for an "Unused" field (the value of which MUST be set to 0),=20
> followed by
>=20
> a fix length value field of 4 bytes specifying the request-id-number
>=20
> that correspond to the missing request.
>=20
> The REQ-MISSING TLV is padded to eight-byte alignment.
>=20
>=20
>=20
> TYPE: To be assigned by IANA
>=20
> LENGTH: 4
>=20
> VALUE: request-id-number that corresponds to the missing request"
>=20
>=20
>=20
> I think the LENGTH field should be set to 6, the unused field=20
> 2 bytes being=20
> part of the Value field. Otherwise
>=20
> it means those 2 bytes are part of the TLV header and it=20
> should be said that=20
> all TLVs will be formatted with
>=20
> this 4 bytes header i.e. Type (1byte) - Value field Length=20
> (1byte) - Unused=20
> field (2bytes) - Value field
>=20
> Otherwise, there may be some problem when decoding a message=20
> with unknown=20
> TLV.
>=20
>=20
>=20
> Besides I'm not sure about the "The REQ-MISSING TLV is padded=20
> to eight-byte=20
> alignment." statement.
>=20
> Is it really needed?
>=20
>=20
>=20
> For the NO-PATH-VECTOR TLV we have
>=20
>=20
>=20
> "The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte
>=20
>    specifying the number of bytes in the value field,=20
> followed by a fix
>=20
>    length value field of 32-bits flags field used to report the
>=20
>    reason(s) that led to unsuccessful path computation.
>=20
>=20
>=20
>    The NO-PATH-VECTOR TLV is padded to eight-byte alignment.
>=20
>=20
>=20
> TYPE: To be assigned by IANA
>=20
>=20
>=20
>    LENGTH: 4
>=20
>=20
>=20
>    VALUE: 32-bits flags field"
>=20
>=20
>=20
> In this case there is no Unused field 2 bytes.
>=20
> I think it would be better to have the same format for all=20
> TLVs of all=20
> object.
>=20
> And again I'm wondering if the LENGTH field should be set to 4 or 6?
>=20
>=20
>=20
> Can you please clarify this to me? Am I missing something?
>=20
>=20
>=20
> Thanks
>=20
> Fabien
>=20
>=20
>=20
>=20
>=20
>=20
> --------------------------------------------------------------
> ------------------
>=20
>=20
> > _______________________________________________
> > Pce mailing list
> > Pce@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/pce
> >=20
>=20
>=20
>=20


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Tue Oct 09 06:46:06 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IfCai-0003Xx-25; Tue, 09 Oct 2007 06:45:32 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IfCag-0003St-OT
	for pce-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 06:45:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IfCag-0003Sl-Ez
	for pce@ietf.org; Tue, 09 Oct 2007 06:45:30 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfCaX-0001f1-W1
	for pce@ietf.org; Tue, 09 Oct 2007 06:45:30 -0400
X-IronPort-AV: E=Sophos;i="4.21,248,1188802800"; 
	d="scan'208,217";a="179825769"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-5.cisco.com with ESMTP; 09 Oct 2007 03:45:17 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l99AjHhs008377; 
	Tue, 9 Oct 2007 03:45:17 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l99AjCPC007514;
	Tue, 9 Oct 2007 10:45:12 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 9 Oct 2007 03:45:12 -0700
Received: from [192.168.10.113] ([10.21.114.181]) by
	xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 9 Oct 2007 03:45:11 -0700
Mime-Version: 1.0 (Apple Message framework v752.2)
References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com>
Message-Id: <14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
From: JP Vasseur <jvasseur@cisco.com>
Subject: Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
Date: Mon, 8 Oct 2007 16:35:57 -0400
To: pce@ietf.org, Lou Berger <lberger@labn.net>,
	Igor Bryskin <ibryskin@movaz.com>,
	Dimitri Papadimitriou <dpapadimitriou@psg.com>, gash5107@yahoo.com
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 09 Oct 2007 10:45:12.0108 (UTC)
	FILETIME=[77FAA6C0:01C80A61]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7163; t=1191926717;
	x=1192790717; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jvasseur@cisco.com;
	z=From:=20JP=20Vasseur=20<jvasseur@cisco.com>
	|Subject:=20Fwd=3A=20[Pce]=20Update=20on=20draft-ietf-pce-policy-enabled-
	path-comp |Sender:=20;
	bh=sSqt6VjJswzlzeruDfJ3T2E4zViLpDykUD3LrJbvkRU=;
	b=sy6cWXaAreO7t0Ll0hElTVgiStq+LKnS/Iw0+dZaatOIENdxwM00eJDtD7sbBp9TDdOfiaaU
	WQpakTkIhKBCSr/6jBtrL1c31gh9sqNqaK3ge8o1x6H0R/7U/IYbrOR9;
Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: -2.2 (--)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: Thomas Walsh <twalsh@juniper.net>,
	JACQUENET Christian RD-DDEV-REN <christian.jacquenet@orange-ftgroup.com>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1930352999=="
Errors-To: pce-bounces@lists.ietf.org


--===============1930352999==
Content-Type: multipart/alternative; boundary=Apple-Mail-104-967676225


--Apple-Mail-104-967676225
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Dear WG,

Christian Jacquenet on behalf of IPSphere proposed to make several  
comments on this document.
Christian, could you please send them to the list ?

As agreed, we're still planning to issue a WG LC after this round of  
discussion.

Thanks.

JP.

Begin forwarded message:

> From: JP Vasseur <jvasseur@cisco.com>
> Date: September 18, 2007 2:10:12 PM EDT
> To: pce@ietf.org, Lou Berger <lberger@labn.net>, Igor Bryskin  
> <ibryskin@movaz.com>, Dimitri Papadimitriou  
> <dpapadimitriou@psg.com>, gash5107@yahoo.com
> Cc: Thomas Walsh <twalsh@juniper.net>, JACQUENET Christian RD-TCH- 
> REN <christian.jacquenet@francetelecom.com>
> Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
>
> Dear WG,
>
> From the WG minutes of the IETF-69 meeting:
>
> 12) Update on Policy-Enabled Path Computation Framework
> draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]
>
> Lou> ready for Last Call
> JP> It sounds ready. Suggestion: offer IPSphere to have a look at  
> the doc before last call. JP will be the point
> of contact. Asked Ross whether this is a good idea, and Ross  
> agreed. Once comments are received, last call.
> Adrian> OK, but this is not an indefinite consultation. We want to  
> be able to move ahead and complete the I-D
> relatively soon.
>
> We have contacted IPSphere and RA WG of IPSphere should provide us  
> some feed-back by
> mid-October. I have copied Tom Walsh and Christian Jacquenet (chair  
> of the RAWG) IPSphere.
>
> Thanks.
>
> JP.
> _______________________________________________
> Pce mailing list
> Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce


--Apple-Mail-104-967676225
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=US-ASCII

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">
Dear WG,<div><br class=3D"webkit-block-placeholder"></div><div>Christian =
Jacquenet on behalf of IPSphere proposed to make several comments on =
this document.</div><div>Christian, could you please send them to the =
list ?</div><div><br class=3D"webkit-block-placeholder"></div><div>As =
agreed, we're still planning to issue a WG LC after this round of =
discussion.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>Thanks.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>JP.<br><div><br><div>Begin =
forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px =
Helvetica">JP Vasseur &lt;<a =
href=3D"mailto:jvasseur@cisco.com">jvasseur@cisco.com</a>&gt;</font></div>=
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><b>Date: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px =
Helvetica">September 18, 2007 2:10:12 PM EDT</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><b>To: </b></font><font =
face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px Helvetica"><a =
href=3D"mailto:pce@ietf.org">pce@ietf.org</a>, Lou Berger &lt;<a =
href=3D"mailto:lberger@labn.net">lberger@labn.net</a>&gt;, Igor Bryskin =
&lt;<a href=3D"mailto:ibryskin@movaz.com">ibryskin@movaz.com</a>&gt;, =
Dimitri Papadimitriou &lt;<a =
href=3D"mailto:dpapadimitriou@psg.com">dpapadimitriou@psg.com</a>&gt;, =
<a =
href=3D"mailto:gash5107@yahoo.com">gash5107@yahoo.com</a></font></div><div=
 style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><b>Cc: </b></font><font =
face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px Helvetica">Thomas =
Walsh &lt;<a =
href=3D"mailto:twalsh@juniper.net">twalsh@juniper.net</a>&gt;, JACQUENET =
Christian RD-TCH-REN &lt;<a =
href=3D"mailto:christian.jacquenet@francetelecom.com">christian.jacquenet@=
francetelecom.com</a>&gt;</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"5" color=3D"#000000" style=3D"font: 16.0px =
Helvetica; color: #000000"><b>Subject: </b></font><font face=3D"Helvetica"=
 size=3D"5" style=3D"font: 16.0px Helvetica"><b>[Pce] Update on =
draft-ietf-pce-policy-enabled-path-comp</b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div> Dear WG,<div><br =
class=3D"webkit-block-placeholder"></div><div>=46rom the WG minutes of =
the IETF-69 meeting:<br> <div><br =
class=3D"webkit-block-placeholder"></div><div><div><i>12) Update on =
Policy-Enabled Path Computation =
Framework</i></div><div><i>draft-ietf-pce-policy-enabled-path-comp-01.txt =
(Lou - 5mn) [110]</i></div><div><i><br =
class=3D"webkit-block-placeholder"></i></div><div><i>Lou&gt; ready for =
Last Call</i></div><div><i>JP&gt; It sounds ready. Suggestion: offer =
IPSphere to have a look at the doc before last call. JP will be the =
point</i></div><div><i>of contact. Asked Ross whether this is a good =
idea, and Ross agreed. Once comments are received, last =
call.</i></div><div><i>Adrian&gt; OK, but this is not an indefinite =
consultation. We want to be able to move ahead and complete the =
I-D</i></div><div><i>relatively soon.</i></div></div><div><br =
class=3D"webkit-block-placeholder"></div><div>We have contacted IPSphere =
and RA WG of IPSphere should provide us some feed-back =
by</div><div>mid-October. I have copied Tom Walsh and Christian =
Jacquenet (chair of the RAWG) IPSphere.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>Thanks.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>JP.</div></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; =
">_______________________________________________</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Pce mailing list</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"mailto:Pce@lists.ietf.org">Pce@lists.ietf.org</a></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"https://www1.ietf.org/mailman/listinfo/pce">https://www1.ietf.org/=
mailman/listinfo/pce</a></div> =
</blockquote></div><br></div></body></html>=

--Apple-Mail-104-967676225--



--===============1930352999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============1930352999==--





From pce-bounces@lists.ietf.org Tue Oct 09 09:40:32 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IfFJ9-0002gr-0V; Tue, 09 Oct 2007 09:39:35 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IfFJ7-0002ga-M2
	for pce-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 09:39:33 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFJ7-0002SI-AR
	for pce@ietf.org; Tue, 09 Oct 2007 09:39:33 -0400
Received: from smtp1.mail.atosorigin.com ([160.92.103.80]
	helo=wpwuee01s.mail.mercury.atosorigin.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfFJ3-0003PD-MF
	for pce@ietf.org; Tue, 09 Oct 2007 09:39:30 -0400
Received: from wpwuee01s.mail.mercury.atosorigin.com (localhost [127.0.0.1])
	by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id
	6A93AF401A for <pce@ietf.org>; Tue,  9 Oct 2007 15:39:28 +0200 (CEST)
Received: from AOFR11476 (unknown [10.10.10.10])
	by wpwuee01s.mail.mercury.atosorigin.com (Postfix) with ESMTP id
	34881F4002 for <pce@ietf.org>; Tue,  9 Oct 2007 15:39:28 +0200 (CEST)
From: "Fabien VERHAEGHE" <fabien.verhaeghe@marben-products.com>
To: <pce@ietf.org>
Date: Tue, 9 Oct 2007 15:38:28 +0200
Message-ID: <004001c80a79$ad36cef0$18600337@AOFR11476>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcgKeayGBFAu7sGBQQya+uTfB3BjgA==
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 142a000676f5977e1797396caab8b611
Cc: 
Subject: [Pce] PathRequests with same RqId
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: fabien.verhaeghe@marben-products.com
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1202702137=="
Errors-To: pce-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1202702137==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0041_01C80A8A.70BF9EF0"

This is a multi-part message in MIME format.

------=_NextPart_000_0041_01C80A8A.70BF9EF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

I have a little concern with PCEP draft.

 

At the end of section 7.3.1 it is said:

"If no path computation reply is received from the PCE, and the PCC wishes
to resend its

   request, the same Request-ID-number MUST be used."

 

I'm not sure what is the purpose here. Is it a kind of retransmission
process in case no reply is received

after N seconds or is it to offer the possibility to the PCC to change the
Path Computation constraints?

(Actually I guess the intent is the first one, but the draft does not forbid
the second case explicitly).

 

In the latter case I think there is a collision case to handle here if the
PCC resends the request at the same time

the PCE sends the reply for the first request.

The PCC cannot know if the reply is for the first request or the second one.

 

In the first case the 2 PathRequests are identical so the problem is less
important except that the PCC may receive 2 responses

(that may not be identical).

 

Another problem is that if the PathRequest belongs to an SVEC and if there
is a collision between a resent PathRequest

and the PathReply, the PCE may not remember the SVEC (since it already
replied) so the second received PathReply result

would not have been performed synchronously with other PathRequests of the
SVEC. 

 

Wouldn't it be preferable to forbid the reuse of a request id? If a PCC
wants to resend a PathRequest it can

send a Cancel Request Notification followed by a new PathRequest with a new
Id. It seems more straight forward and robust to me.

 

Actually I'm not sure I get the advantage of reusing the same request Id.

 

Best regards

Fabien

 


------=_NextPart_000_0041_01C80A8A.70BF9EF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:navy;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DFR link=3Dblue vlink=3Dnavy>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Hello,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>I have a little concern with PCEP =
draft.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>At the end of section 7.3.1 it is =
said:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&#8220;If no path computation reply is =
received from
the PCE, and the PCC wishes to resend its<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;&nbsp; request, the same =
Request-ID-number MUST
be used.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>I&#8217;m not sure what is the purpose here. =
Is it a
kind of retransmission process in case no reply is =
received<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>after N seconds or is it to offer the =
possibility to
the PCC to change the Path Computation =
constraints?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>(Actually I guess the intent is the first one, =
but
the draft does not forbid the second case =
explicitly).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>In the latter case I think there is a =
collision case
to handle here if the PCC resends the request at the same =
time<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>the PCE sends the reply for the first =
request.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>The PCC cannot know if the reply is for the =
first
request or the second one.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>In the first case the 2 PathRequests are =
identical so
the problem is less important except that the PCC may receive 2 =
responses<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>(that may not be =
identical).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Another problem is that if the PathRequest =
belongs to
an SVEC and if there is a collision between a resent =
PathRequest<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>and the PathReply, the PCE may not remember =
the SVEC
(since it already replied) so the second received PathReply =
result<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>would not have been performed synchronously =
with
other PathRequests of the SVEC. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Wouldn&#8217;t it be preferable to forbid the =
reuse
of a request id? If a PCC wants to resend a PathRequest it =
can<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>send a Cancel Request Notification followed by =
a new
PathRequest with a new <st1:State w:st=3D"on"><st1:place =
w:st=3D"on">Id.</st1:place></st1:State>
It seems more straight forward and robust to =
me.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Actually I&#8217;m not sure I get the =
advantage of
reusing the same request <st1:State w:st=3D"on"><st1:place =
w:st=3D"on">Id.</st1:place></st1:State><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Best regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Fabien<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0041_01C80A8A.70BF9EF0--




--===============1202702137==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============1202702137==--






From pce-bounces@lists.ietf.org Wed Oct 10 14:59:08 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IfglW-0001cO-Qt; Wed, 10 Oct 2007 14:58:42 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IfglV-0001cB-L2
	for pce-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 14:58:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IfglV-0001c2-B5
	for pce@ietf.org; Wed, 10 Oct 2007 14:58:41 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfglU-0004rZ-3h
	for pce@ietf.org; Wed, 10 Oct 2007 14:58:41 -0400
X-IronPort-AV: E=Sophos;i="4.21,255,1188792000"; d="scan'208";a="73685885"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2007 14:58:39 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9AIwctY011428; 
	Wed, 10 Oct 2007 14:58:38 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9AIwGrk012756; 
	Wed, 10 Oct 2007 18:58:34 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 10 Oct 2007 14:58:32 -0400
Received: from [10.71.0.161] ([10.86.242.199]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 10 Oct 2007 14:58:31 -0400
In-Reply-To: <005401c80685$2068b850$5102010a@your029b8cecfe>
References: <001c01c8065d$70897180$18600337@AOFR11476>
	<D109C8C97C15294495117745780657AE0873382E@ftrdmel1>
	<005401c80685$2068b850$5102010a@your029b8cecfe>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <E57A9CA6-00DE-4CEC-A218-792AC8CA125E@cisco.com>
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <jvasseur@cisco.com>
Subject: Re: [Pce] TLV Format
Date: Wed, 10 Oct 2007 19:53:44 +0200
To: Adrian Farrel <adrian@olddog.co.uk>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 10 Oct 2007 18:58:32.0137 (UTC)
	FILETIME=[8D626390:01C80B6F]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15474.002
X-TM-AS-Result: No--20.857700-8.000000-2
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6542; t=1192042718;
	x=1192906718; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jvasseur@cisco.com;
	z=From:=20JP=20Vasseur=20<jvasseur@cisco.com>
	|Subject:=20Re=3A=20[Pce]=20TLV=20Format |Sender:=20
	|To:=20Adrian=20Farrel=20<adrian@olddog.co.uk>;
	bh=CuOSBggRYFsSPAm1VAfPLBZ4/ydX123PfJhqXKl5BLc=;
	b=PLLTXtWQW3p0aSqFcmH/sB/hNPCOoCcl/vUH1oK5rgHhuuBVFk61sYiqzcDMAAlwYKeTlToT
	yTETJd6mwqsS5z+sl1FEBRyLQ+AhDuH56gqplaKwYULZcdUPInT7mqUV;
Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf
Cc: pce@ietf.org
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hi,

On Oct 4, 2007, at 2:50 PM, Adrian Farrel wrote:

> Hi,
>
> Did you see the question about padding and lengths on the CCAMP and =20=

> OSPF lists?
>
> It might be worth getting this explained in the PCEP I-D, as well. =20
> The questions are:
>
> When an object contains a TLV with padding (so the TLV length field =20=

> does not include the length of the padding) what is the value of =20
> the length field in the object?
>
> When a TLV contains multiple TLVs with padding, what is the value =20
> of the length field in the object?
>
> When a TLV contains sub-TLVs with padding, what is the value of the =20=

> length field in the TLV?
>
> These three questions seem to have well-known and "obvious" answers =20=

> for other protocols, but are not written down. Let's write them =20
> down for PCEP.

This is planned for rev-09 for sure.

Thanks.

Cheers.

JP.

>
> Cheers,
> Adrian
>
> ----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN" =20=

> <jeanlouis.leroux@orange-ftgroup.com>
> To: <fabien.verhaeghe@marben-products.com>; <pce@ietf.org>
> Sent: Thursday, October 04, 2007 10:25 AM
> Subject: RE: [Pce] TLV Format
>
>
> Hi Fabien
>
> Sorry for the late reply
>
> Please see inline,
>
>
> ________________________________
>
> De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]
> Envoy=E9 : jeudi 4 octobre 2007 10:06
> =C0 : pce@ietf.org
> Objet : TR: [Pce] TLV Format
>
>
>
> Hello,
>
>
>
> I did not see any reply for this comment.
>
> I seize the opportunity to clarify my opinion:
>
>
>
> I think TLV alignment statement must be a general rules for all =20
> TLVs of a given object.
>
>
>
> Definitely right. We are going to add a section on generic TLV =20
> encoding. All TLVs specificed in PCEP objects will have to follow =20
> this encoding.
>
>
>
> Here it is:
>
>
>
>
>
> 7.1.1. PCEP Object TLVs
>
>
>
> A PCEP object may include a set of one or more optional TLV(s).
> A PCEP object TLV is comprised of 2 octets for the type, 2 octets =20
> specifying the TLV length,
> and a value field. The Length field defines the length of the value =20=

> portion in octets.
> The TLV is padded to four-octet alignment; padding is not included =20
> in the Length field
> (so a three octet value would have a length of three, but the total =20=

> size of the TLV would
> be eight octets).
>
> PCEP Object TLV types MUST be managed by IANA.
>
> Unrecognized TLVs MUST be ignored.
>
>
>
>
>
> Note that this is the encoding already used in RFC 3630 & 4420.
>
>
>
>
>
>
>
> The draft then needs also to specify that the alignment padding =20
> bytes must be included before
>
> or after the value field.
>
>
>
> The Length field would carry the actual length of the value without =20=

> padding bytes due to alignment.
>
>
>
> Those statements seem important to me for the processing of unknown =20=

> TLVs.
>
>
>
> Sure
>
>
>
> With this general rules there is no need to specify that 2 unused =20
> bytes must be added for 4 bytes length
>
> value TLV such as The REQ-MISSING.
>
>
>
> Note that I'm not sure why the draft proposed a 8 bytes alignment =20
> (Why not 4 bytes since in section 7.1
>
> it is said that object length must always be a multiple of 4?).
>
>
>
> Yes this was a mistake. We are going to align TLV definitions to =20
> new section 7.1.1.
>
>
>
> Thanks for your comment.
>
>
>
> Regards,
>
>
>
> JL
>
>
>
> Does it make sense?
>
>
>
> Best regards
>
> Fabien
>
>
>
>
>
>
> ________________________________
>
>
> De : Fabien VERHAEGHE [mailto:fabien.verhaeghe@marben-products.com]
> Envoy=E9 : vendredi 14 septembre 2007 09:45
> =C0 : pce@ietf.org
> Objet : [Pce] TLV Format
>
>
>
> Hi,
>
>
>
> I think there is a little problem with PCEP object TLV format.
>
>
>
> The main problem being that the general format of the TLVs is not =20
> described (Type, length value length, 4 bytes alignment...).
>
>
>
> Besides for existing TLVs we have:
>
>
>
>
>
> "The REQ-MISSING TLV is composed of 1 byte for the type,
>
> 1 byte specifying the number of bytes in the value field, 2 bytes
>
> for an "Unused" field (the value of which MUST be set to 0), =20
> followed by
>
> a fix length value field of 4 bytes specifying the request-id-number
>
> that correspond to the missing request.
>
> The REQ-MISSING TLV is padded to eight-byte alignment.
>
>
>
> TYPE: To be assigned by IANA
>
> LENGTH: 4
>
> VALUE: request-id-number that corresponds to the missing request"
>
>
>
> I think the LENGTH field should be set to 6, the unused field 2 =20
> bytes being part of the Value field. Otherwise
>
> it means those 2 bytes are part of the TLV header and it should be =20
> said that all TLVs will be formatted with
>
> this 4 bytes header i.e. Type (1byte) - Value field Length (1byte) =20
> - Unused field (2bytes) - Value field
>
> Otherwise, there may be some problem when decoding a message with =20
> unknown TLV.
>
>
>
> Besides I'm not sure about the "The REQ-MISSING TLV is padded to =20
> eight-byte alignment." statement.
>
> Is it really needed?
>
>
>
> For the NO-PATH-VECTOR TLV we have
>
>
>
> "The NO-PATH-VECTOR TLV is composed of 1 byte for the type, 1 byte
>
>   specifying the number of bytes in the value field, followed by a fix
>
>   length value field of 32-bits flags field used to report the
>
>   reason(s) that led to unsuccessful path computation.
>
>
>
>   The NO-PATH-VECTOR TLV is padded to eight-byte alignment.
>
>
>
> TYPE: To be assigned by IANA
>
>
>
>   LENGTH: 4
>
>
>
>   VALUE: 32-bits flags field"
>
>
>
> In this case there is no Unused field 2 bytes.
>
> I think it would be better to have the same format for all TLVs of =20
> all object.
>
> And again I'm wondering if the LENGTH field should be set to 4 or 6?
>
>
>
> Can you please clarify this to me? Am I missing something?
>
>
>
> Thanks
>
> Fabien
>
>
>
>
>
>
> ----------------------------------------------------------------------=20=

> ----------
>
>
>> _______________________________________________
>> Pce mailing list
>> Pce@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/pce
>
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Thu Oct 11 07:12:04 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ifvx2-0007w1-A9; Thu, 11 Oct 2007 07:11:36 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1Ifvx0-0007ub-9z
	for pce-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 07:11:34 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifvwz-0007sB-Tm
	for pce@ietf.org; Thu, 11 Oct 2007 07:11:33 -0400
Received: from guadiana.unex.es ([158.49.17.23])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifvwx-0005qB-9p
	for pce@ietf.org; Thu, 11 Oct 2007 07:11:31 -0400
Received: from [158.49.122.70] (unknown [158.49.122.70])
	by guadiana.unex.es (Postfix) with ESMTP id 137F11FDD5;
	Thu, 11 Oct 2007 13:06:15 +0200 (CEST)
Message-ID: <470E03A6.2010309@unex.es>
Date: Thu, 11 Oct 2007 13:06:14 +0200
From: Manuel Dominguez Dorado <mdomdor@unex.es>
Organization: University of Extremadura
User-Agent: Thunderbird 2.0.0.5 (X11/20070727)
MIME-Version: 1.0
To: pce@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
Subject: [Pce] Loops in path computation
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mdomdor@unex.es
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hello,

I've been reading PCE works for about a year. I cannot find any document=20
that explains how to avoid loops in interdomain PCE path computation. I=20
don't know if there is a specific doc that covers this issue.

Do you know something more?

Regards.


--=20
------------------------------------------------------------------------
                         MANUEL DOM=CDNGUEZ DORADO
------------------------------------------------------------------------
Addr.: Laboratorio de Ingenier=ED=ADa Telem=E1tica
        Escuela Polit=E9cnica de C=E1ceres
        =C1rea de Ingenier=ED=ADa Telem=E1tica
        Departamento de Ingenier=ED=ADa de Sistemas Inform=E1ticos y Tele=
m=E1ticos
        Universidad de Extremadura
        Avda. de la Universidad s/n. 10071 - C=E1ceres - SPAIN
Phone: +34 607 417 860
Fax..: +34 927 257 202
Email: mdomdor@unex.es
Web.:: http://gitaca.unex.es/manolodd
------------------------------------------------------------------------


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Thu Oct 11 08:01:01 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IfwiS-0006JC-Hd; Thu, 11 Oct 2007 08:00:36 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IfwiP-0006HM-Ew
	for pce-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 08:00:33 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IfwiO-0006HE-V7
	for pce@ietf.org; Thu, 11 Oct 2007 08:00:33 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfwiO-0007P2-AQ
	for pce@ietf.org; Thu, 11 Oct 2007 08:00:32 -0400
Received: from [88.96.235.138] (helo=cortex.aria-networks.com)
	by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IfwiJ-0001xJ-Vs
	for pce@ietf.org; Thu, 11 Oct 2007 12:00:28 +0000
Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by
	cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 11 Oct 2007 13:00:27 +0100
Message-ID: <0bf801c80bfe$4d5b7fe0$5102010a@your029b8cecfe>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <pce@ietf.org>
References: <470E03A6.2010309@unex.es>
Subject: Re: [Pce] Loops in path computation
Date: Thu, 11 Oct 2007 13:00:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 11 Oct 2007 12:00:27.0375 (UTC)
	FILETIME=[501D37F0:01C80BFE]
X-Originating-Heisenberg-IP: [88.96.235.138]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hello Manuel,

> I've been reading PCE works for about a year. I cannot find any document 
> that explains how to avoid loops in interdomain PCE path computation. I 
> don't know if there is a specific doc that covers this issue.
>
> Do you know something more?

I assume you mean how to avoid loops created by re-entering a domain (loops
within a domain are simply the job of the computation algorithm).

So far, little attention has been given to the selection of the sequence of
domains to be crossed by an inter-domain path. Although it is recognised as
a potential element to computation techniques it is also known that initial
deployments will be severely gated by administrative and commercial
limitations (e.g., inter-AS peering agreements) such that the sequence of
domains for a path will be known in advance.

As draft-ietf-pce-brpc-05.txt says:
   The PCE-based BRPC procedure applies to the computation of an optimal
   constrained inter-domain TE LSP.  The sequence of domains to be
   traversed can either be determined a priori or during the path
   computation procedure.  The BRPC procedure guarantees to compute the
   optimal path across a specific sequence of traversed domains (which
   constitutes an additional constraint).  In the case of an arbitrary
   set of meshed domains, the BRPC procedure can be used to compute the
   optimal path across each domain set in order to get the optimal
   constrained path between the source and the destination of the TE
   LSP.  The BRPC procedure can also be used across a subset of all
   domain sequences, and the best path among these sequences is then
   selected.

Note that the brpc technique itself would initially appear to be vulnerable
to looping between PCEs, but the use of a pre-determined list of domains
means that this cannot happen.

And, of course, if you apply the per-domain approach, the sequence of
domains is also known in advance.

More interesting, perhaps, than deliberate re-entry into a domain, is the
selection of the sequence of domains so as to avoid re-entry. This function,
however, sails very close to the wind with regard to our current scope. The
charter says:
   The PCE WG will work on application of this model within a single
   domain or within a small group of domains...
and clearly the selection of the sequence of domains is less interesting if
the number of domains is small.

But, nevertheless, brpc could be used to perform this function (as described
in the quoted text above) by examining the alternative paths that are
available from pre-determined sequences of domains.

Further, the original PCE architects did consider a "hierarchical
cooperative PCE" model whereby a parent PCE is aware of the topology and
connectedness of domains (but not of the content of the domains) and sends
computation requests to the PCEs responsible for each domain. Such a model
is quite close to that expressed in the ITU-T's G.7715.2 (even though the
domains have a somewhat different meaning in that case).

Regards,
Adrian 




_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Thu Oct 11 08:01:04 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ifwiu-00077G-C0; Thu, 11 Oct 2007 08:01:04 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IfDZK-0001MN-U5
	for pce-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 07:48:10 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IfDZK-0001IL-FA
	for pce@ietf.org; Tue, 09 Oct 2007 07:48:10 -0400
Received: from p-mail2.rd.francetelecom.com ([195.101.245.16])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfDZI-0006fs-Ap
	for pce@ietf.org; Tue, 09 Oct 2007 07:48:10 -0400
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 9 Oct 2007 13:47:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
Date: Tue, 9 Oct 2007 13:47:55 +0200
Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0F5FB42B@ftrdmel2>
In-Reply-To: <14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
Thread-Index: AcgKYX0aB3RhCvsaTjipbB0IA5rXVwACGt+A
References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com>
	<14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
From: "JACQUENET Christian RD-DDEV-REN"
	<christian.jacquenet@orange-ftgroup.com>
To: "JP Vasseur" <jvasseur@cisco.com>, <pce@ietf.org>,
	"Lou Berger" <lberger@labn.net>, "Igor Bryskin" <ibryskin@movaz.com>,
	"Dimitri Papadimitriou" <dpapadimitriou@psg.com>, <gash5107@yahoo.com>
X-OriginalArrivalTime: 09 Oct 2007 11:47:40.0738 (UTC)
	FILETIME=[32563220:01C80A6A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 645960076aa293effd9740db2f975dc3
X-Mailman-Approved-At: Thu, 11 Oct 2007 08:01:02 -0400
Cc: Thomas Walsh <twalsh@juniper.net>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1595384019=="
Errors-To: pce-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1595384019==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C80A6A.37D060F8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C80A6A.37D060F8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,
=20
Please find herein my comments, which are *not* on behalf of the IPSF - =
only personal :-)
1. General:

	I think this is a very useful document that clearly identifies the =
advantages of policy-based path computation management in PCE =
environments. Nevertheless, I would encourage a refined organization of =
the document, which would distinguish between the framework (current =
sections 2.1, 4 and 5 basically), the requirements (section 3, but also =
part of the text that relates to scenarios) and use cases or scenarios =
(sections 2.2.x, a bit of sections 7 and 8).

2. Section 2.1, page 5:

	The introductory sentence of the third paragraph implicly indicates =
that PCE may very well behave as either a PDP (makes decisions to be =
applied by PCC clients for example) or a PEP (applies decisions possibly =
made by PCC clients and/or other PCE components). I think this is one of =
the very key notions introduced by this draft, and would therefore =
suggest an introductory section that would elaborate on this heuristic, =
possibly after the reminder about basic concepts of policy-based =
management.

3. Section 2.1, page 6:

	The last sentence of the first paragraph is slightly confusing: I don't =
think the "or" is exclusive, that is, provider-defined policies might =
very well be real time.

4. Section 2.2.3, page 11:

	What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP or =
both? I think this should be elaborated, possibly in the Terminology =
section. Note also that the last sentence of the page mixes the notions =
of "making decision" and "apply user or service-specific policies": =
since the text introduces a kind of causality effect (the PEP embedded =
in the PCC enforces user or service-specific policies, which seems to =
result in soliciting the PDP embedded in the PEP to make decisions about =
the scope of constraints that need to be taken into account for path =
computation purposes), I would suggest a kind of flow diagram that could =
possibly elaborate on the corresponding chronology.

5. Section 2.2.3, page 12:

	Related to the comment above, the sentence "when deciding..." of the =
first paragraph may also suggest the activation of a LPDP capability. I =
would also elaborate on the possible interactions between the PEP, the =
PDP and the possible LPDP capabilities that may be embedded in the PCC, =
assuming a differentiation "a la COPS Client-Type". Who's the destinee =
of the path computation request in the "once the constraints..." =
sentence of the same paragraph - the PCE?

	In the third paragraph, it seems that (1) The PCC embeds a PDP that =
makes decisions about constraint-defined policies, (2) Sends a path =
computation request that conveys the aforementioned policy information =
towards the PCE, whose embedded PEP (3) Applies the corresponding =
decisions: is this statement correct? If so, I don't understand why the =
PCE may "decide to reject the request": that is, from a policy =
management standpoint, only the PEP of the PCE is solicited in this =
context, which means that the PEP may not be capable of enforcing the =
decision, but I don't think the PEP is entitled to *reject* the =
decision, as part of a decision making process. Maybe it's a wording =
issue.

	What would be the conditions to send path computation requests to more =
than one PCE, aside from an inter-domain context? I'm not sure I =
understand why the response sent by the PCE-PEP back to the requesting =
PCC-PDP may indicate *policies*. Unless the document refers to a kind of =
PCE-inferred feedback PIB (RFC 3571)? In that case, I would elaborate.

6. Section 3, page 15:

	The notion of trusted nodes (as introdcued in the third paragraph) =
should deserve some elaboration, IMHO. The security considerations of =
this page should either be extended (e.g. preservation of the =
confidentiality of the information that will be exchanged between a PDP =
and a set of PDPs), or reference the "true" Security Considerations =
section of the document, which BTW, rightfully elaborates on such =
issues.

7. Section 5, page 18:

	I don't understand why a protocol like COPS couldn't be used in the =
case where PEP and PDP are colocated. In any case, a protocol is =
required to convey the exchanges between the PEP and the PDP...

	In addition (last line of the page), it's very unlikely that SNMP will =
be used to retrieve information from a PIB.

8. Section 5, page 19:

	I would suggest some elaboration on the kind of information any given =
PEP (PCC or PCE) may receive from another *PEP* - is this a typo (i.e. =
read PDP instead), or does this relate to information different from =
"policy-related" information or else? In a COPS context, multiple =
Client-Types can certainly reside and coexist within a PEP, but I'm not =
sure I understand why PEPs would exchange information.

	Also, the following paragraph ("any given policy...") is a bit =
confusing to me: I don't understand this notion of partial =
interpretation, and would rather suggest another wording - enforcement =
instead of interpretation. Besides, I'm not sure this paragraph helps in =
understanding the roles played by PEPs and PDPs.

9. Section 6.1., page 20:

	Why *all* PC policy types used in the net *must* be applied? It's a =
"Client-Type" specific thing, IMHO.

10. Section 6.1., page 21:

	In the first paragraph, I don't understand why the PCE selection should =
be static. Even if the policy enforcement is restricted to the PCE (for =
path computation purposes), nothing prevents a PEP embedded in a PCC to =
support the relevant "Client-Type", hence yielding the dynamic =
identification of the corresponding PCE, by means of the COPS-like OPEN =
message at PCC bootstrap, for example.

	In the third paragraph, the "must" of the first sentence is too strong, =
IMHO, unless the sentence means that any kind of policy must "encouarge" =
the support of the corresponding "Client-Types" in the PCC-PEP. If so, I =
would rephrase.

11. Section 6.2., page 22:

	I don't understand why matching repositories would result in a single =
PC repository, unless further elaboration on such match is provided.

12. Section 6.3, page 23:

	Does the figure relate to PCE instead of PCC (same for figure 12)?

13. Section 7.1., page 25:

	What's an "objection function"?

14. Typos:

	TED =3D Traffic Engineering Database?

	SRLG =3D Shared Risk Link Group?

	Page 16, provide the normative reference associated to LDAPv3.

	Page 17, remove the "s" of the very last word of the page.

Cheers,

Christian.


________________________________

De : JP Vasseur [mailto:jvasseur@cisco.com]=20
Envoy=E9 : lundi 8 octobre 2007 22:36
=C0 : pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri Papadimitriou; =
gash5107@yahoo.com
Cc : Thomas Walsh; JACQUENET Christian RD-DDEV-REN
Objet : Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp


Dear WG,=20

Christian Jacquenet on behalf of IPSphere proposed to make several =
comments on this document.
Christian, could you please send them to the list ?

As agreed, we're still planning to issue a WG LC after this round of =
discussion.

Thanks.

JP.


Begin forwarded message:


	From: JP Vasseur <jvasseur@cisco.com>
	Date: September 18, 2007 2:10:12 PM EDT
	To: pce@ietf.org, Lou Berger <lberger@labn.net>, Igor Bryskin =
<ibryskin@movaz.com>, Dimitri Papadimitriou <dpapadimitriou@psg.com>, =
gash5107@yahoo.com
	Cc: Thomas Walsh <twalsh@juniper.net>, JACQUENET Christian RD-TCH-REN =
<christian.jacquenet@francetelecom.com>
	Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

	Dear WG,=20

	From the WG minutes of the IETF-69 meeting:
=09

	12) Update on Policy-Enabled Path Computation Framework
	draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]
=09
=09
	Lou> ready for Last Call
	JP> It sounds ready. Suggestion: offer IPSphere to have a look at the =
doc before last call. JP will be the point
	of contact. Asked Ross whether this is a good idea, and Ross agreed. =
Once comments are received, last call.
	Adrian> OK, but this is not an indefinite consultation. We want to be =
able to move ahead and complete the I-D
	relatively soon.

	We have contacted IPSphere and RA WG of IPSphere should provide us some =
feed-back by
	mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of =
the RAWG) IPSphere.

	Thanks.

	JP.
	_______________________________________________
	Pce mailing list
	Pce@lists.ietf.org
	https://www1.ietf.org/mailman/listinfo/pce



------_=_NextPart_001_01C80A6A.37D060F8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space">
<DIV dir=3Dltr align=3Dleft><SPAN class=3D043374511-09102007><FONT =
face=3D"Courier New"=20
color=3D#0000ff size=3D2>Dear all,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D043374511-09102007><FONT =
face=3D"Courier New"=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D043374511-09102007><FONT =
face=3D"Courier New"=20
color=3D#0000ff size=3D2>Please find herein my comments, which are *not* =
on behalf=20
of the IPSF - only personal :-)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D043374511-09102007>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>1. =
General:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>I think this is a =
very useful=20
document that clearly identifies the advantages of policy-based path =
computation=20
management in PCE environments. Nevertheless, I would encourage a =
refined=20
organization of the document, which would distinguish between the =
framework=20
(current sections 2.1, 4 and 5 basically), the requirements (section 3, =
but also=20
part of the text that relates to scenarios) and use cases or scenarios =
(sections=20
2.2.x, a bit of sections 7 and 8).</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>2. Section 2.1, =
page=20
5:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>The introductory =
sentence of=20
the third paragraph implicly indicates that PCE may very well behave as =
either a=20
PDP (makes decisions to be applied by PCC clients for example) or a PEP =
(applies=20
decisions possibly made by PCC clients and/or other PCE components). I =
think=20
this is one of the very key notions introduced by this draft, and would=20
therefore suggest an introductory section that would elaborate on this=20
heuristic, possibly after the reminder about basic concepts of =
policy-based=20
management.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>3. Section 2.1, =
page=20
6:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>The last sentence =
of the first=20
paragraph is slightly confusing: I don't think the "or" is exclusive, =
that is,=20
provider-defined policies might very well be real time.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>4. Section 2.2.3, =
page=20
11:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>What's a =
policy-enabled PCC? A=20
PCC that either embeds a PEP, a PDP or both? I think this should be =
elaborated,=20
possibly in the Terminology section. Note also that the last sentence of =
the=20
page mixes the notions of "making decision" and "apply user or =
service-specific=20
policies": since the text introduces a kind of causality effect (the PEP =

embedded in the PCC enforces user or service-specific policies, which =
seems to=20
result in soliciting the PDP embedded in the PEP to make decisions about =
the=20
scope of constraints that need to be taken into account for path =
computation=20
purposes), I would suggest a kind of flow diagram that could possibly =
elaborate=20
on the corresponding chronology.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>5. Section 2.2.3, =
page=20
12:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Related to the =
comment above,=20
the sentence "when deciding=85" of the first paragraph may also suggest =
the=20
activation of a LPDP capability. I would also elaborate on the possible=20
interactions between the PEP, the PDP and the possible LPDP capabilities =
that=20
may be embedded in the PCC, assuming a differentiation "a la COPS =
Client-Type".=20
Who's the destinee of the path computation request in the "once the=20
constraints=85" sentence of the same paragraph - the PCE?</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>In the third =
paragraph, it=20
seems that (1) The PCC embeds a PDP that makes decisions about=20
constraint-defined policies, (2) Sends a path computation request that =
conveys=20
the aforementioned policy information towards the PCE, whose embedded =
PEP (3)=20
Applies the corresponding decisions: is this statement correct? If so, I =
don't=20
understand why the PCE may "decide to reject the request": that is, from =
a=20
policy management standpoint, only the PEP of the PCE is solicited in =
this=20
context, which means that the PEP may not be capable of enforcing the =
decision,=20
but I don't think the PEP is entitled to *reject* the decision, as part =
of a=20
decision making process. Maybe it's a wording issue.</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>What would be the =
conditions to=20
send path computation requests to more than one PCE, aside from an =
inter-domain=20
context? I'm not sure I understand why the response sent by the PCE-PEP =
back to=20
the requesting PCC-PDP may indicate *policies*. Unless the document =
refers to a=20
kind of PCE-inferred feedback PIB (RFC 3571)? In that case, I would=20
elaborate.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>6. Section 3, =
page=20
15:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>The notion of =
trusted nodes (as=20
introdcued in the third paragraph) should deserve some elaboration, =
IMHO. The=20
security considerations of this page should either be extended (e.g.=20
preservation of the confidentiality of the information that will be =
exchanged=20
between a PDP and a set of PDPs), or reference the "true" Security=20
Considerations section of the document, which BTW, rightfully elaborates =
on such=20
issues.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>7. Section 5, =
page=20
18:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>I don't =
understand why a=20
protocol like COPS couldn't be used in the case where PEP and PDP are =
colocated.=20
In any case, a protocol is required to convey the exchanges between the =
PEP and=20
the PDP=85</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>In addition (last =
line of the=20
page), it's very unlikely that SNMP will be used to retrieve information =
from a=20
PIB.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>8. Section 5, =
page=20
19:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>I would suggest =
some=20
elaboration on the kind of information any given PEP (PCC or PCE) may =
receive=20
from another *PEP* - is this a typo (i.e. read PDP instead), or does =
this relate=20
to information different from "policy-related" information or else? In a =
COPS=20
context, multiple Client-Types can certainly reside and coexist within a =
PEP,=20
but I'm not sure I understand why PEPs would exchange =
information.</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Also, the =
following paragraph=20
("any given policy=85") is a bit confusing to me: I don't understand =
this notion=20
of partial interpretation, and would rather suggest another wording -=20
enforcement instead of interpretation. Besides, I'm not sure this =
paragraph=20
helps in understanding the roles played by PEPs and =
PDPs.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>9. Section 6.1., =
page=20
20:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Why *all* PC =
policy types used=20
in the net *must* be applied? It's a "Client-Type" specific thing,=20
IMHO.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>10. Section 6.1., =
page=20
21:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>In the first =
paragraph, I don't=20
understand why the PCE selection should be static. Even if the policy=20
enforcement is restricted to the PCE (for path computation purposes), =
nothing=20
prevents a PEP embedded in a PCC to support the relevant "Client-Type", =
hence=20
yielding the dynamic identification of the corresponding PCE, by means =
of the=20
COPS-like OPEN message at PCC bootstrap, for example.</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>In the third =
paragraph, the=20
"must" of the first sentence is too strong, IMHO, unless the sentence =
means that=20
any kind of policy must "encouarge" the support of the corresponding=20
"Client-Types" in the PCC-PEP. If so, I would rephrase.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>11. Section 6.2., =
page=20
22:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>I don't =
understand why matching=20
repositories would result in a single PC repository, unless further =
elaboration=20
on such match is provided.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>12. Section 6.3, =
page=20
23:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Does the figure =
relate to PCE=20
instead of PCC (same for figure 12)?</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>13.&nbsp;<SPAN=20
class=3D043374511-09102007>S</SPAN>ection 7.1., page 25:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>What's an =
"objection=20
function"?</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>14. =
Typos:</FONT></P>
<DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>TED =3D Traffic =
Engineering=20
Database?</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>SRLG =3D Shared =
Risk Link=20
Group?</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Page 16, provide =
the normative=20
reference associ<SPAN class=3D043374511-09102007>at</SPAN>ed to =
LDAPv3.</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Page 17, remove =
the "s" of the=20
very last word of the page.</FONT></P></DIR>
<P><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>Cheers,</FONT></P>
<P><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2>Christian.</FONT></P></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Dfr dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>De&nbsp;:</B> JP Vasseur =
[mailto:jvasseur@cisco.com]=20
<BR><B>Envoy=E9&nbsp;:</B> lundi 8 octobre 2007 =
22:36<BR><B>=C0&nbsp;:</B>=20
pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri Papadimitriou;=20
gash5107@yahoo.com<BR><B>Cc&nbsp;:</B> Thomas Walsh; JACQUENET Christian =

RD-DDEV-REN<BR><B>Objet&nbsp;:</B> Fwd: [Pce] Update on=20
draft-ietf-pce-policy-enabled-path-comp<BR></FONT><BR></DIV>
<DIV></DIV>Dear WG,
<DIV><BR class=3Dwebkit-block-placeholder></DIV>
<DIV>Christian Jacquenet on behalf of IPSphere proposed to make several =
comments=20
on this document.</DIV>
<DIV>Christian, could you please send them to the list ?</DIV>
<DIV><BR class=3Dwebkit-block-placeholder></DIV>
<DIV>As agreed, we're still planning to issue a WG LC after this round =
of=20
discussion.</DIV>
<DIV><BR class=3Dwebkit-block-placeholder></DIV>
<DIV>Thanks.</DIV>
<DIV><BR class=3Dwebkit-block-placeholder></DIV>
<DIV>JP.<BR>
<DIV><BR>
<DIV>Begin forwarded message:</DIV><BR =
class=3DApple-interchange-newline>
<BLOCKQUOTE type=3D"cite">
  <DIV style=3D"MARGIN: 0px"><FONT style=3D"FONT: 16px Helvetica; COLOR: =
#000000"=20
  face=3DHelvetica color=3D#000000 size=3D5><B>From: </B></FONT><FONT=20
  style=3D"FONT: 16px Helvetica" face=3DHelvetica size=3D5>JP Vasseur =
&lt;<A=20
  =
href=3D"mailto:jvasseur@cisco.com">jvasseur@cisco.com</A>&gt;</FONT></DIV=
>
  <DIV style=3D"MARGIN: 0px"><FONT style=3D"FONT: 16px Helvetica; COLOR: =
#000000"=20
  face=3DHelvetica color=3D#000000 size=3D5><B>Date: </B></FONT><FONT=20
  style=3D"FONT: 16px Helvetica" face=3DHelvetica size=3D5>September 18, =
2007 2:10:12=20
  PM EDT</FONT></DIV>
  <DIV style=3D"MARGIN: 0px"><FONT style=3D"FONT: 16px Helvetica; COLOR: =
#000000"=20
  face=3DHelvetica color=3D#000000 size=3D5><B>To: </B></FONT><FONT=20
  style=3D"FONT: 16px Helvetica" face=3DHelvetica size=3D5><A=20
  href=3D"mailto:pce@ietf.org">pce@ietf.org</A>, Lou Berger &lt;<A=20
  href=3D"mailto:lberger@labn.net">lberger@labn.net</A>&gt;, Igor =
Bryskin &lt;<A=20
  href=3D"mailto:ibryskin@movaz.com">ibryskin@movaz.com</A>&gt;, Dimitri =

  Papadimitriou &lt;<A=20
  href=3D"mailto:dpapadimitriou@psg.com">dpapadimitriou@psg.com</A>&gt;, =
<A=20
  href=3D"mailto:gash5107@yahoo.com">gash5107@yahoo.com</A></FONT></DIV>
  <DIV style=3D"MARGIN: 0px"><FONT style=3D"FONT: 16px Helvetica; COLOR: =
#000000"=20
  face=3DHelvetica color=3D#000000 size=3D5><B>Cc: </B></FONT><FONT=20
  style=3D"FONT: 16px Helvetica" face=3DHelvetica size=3D5>Thomas Walsh =
&lt;<A=20
  href=3D"mailto:twalsh@juniper.net">twalsh@juniper.net</A>&gt;, =
JACQUENET=20
  Christian RD-TCH-REN &lt;<A=20
  =
href=3D"mailto:christian.jacquenet@francetelecom.com">christian.jacquenet=
@francetelecom.com</A>&gt;</FONT></DIV>
  <DIV style=3D"MARGIN: 0px"><FONT style=3D"FONT: 16px Helvetica; COLOR: =
#000000"=20
  face=3DHelvetica color=3D#000000 size=3D5><B>Subject: </B></FONT><FONT =

  style=3D"FONT: 16px Helvetica" face=3DHelvetica size=3D5><B>[Pce] =
Update on=20
  draft-ietf-pce-policy-enabled-path-comp</B></FONT></DIV>
  <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>Dear WG,
  <DIV><BR class=3Dwebkit-block-placeholder></DIV>
  <DIV>From the WG minutes of the IETF-69 meeting:<BR>
  <DIV><BR class=3Dwebkit-block-placeholder></DIV>
  <DIV>
  <DIV><I>12) Update on Policy-Enabled Path Computation =
Framework</I></DIV>
  <DIV><I>draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn)=20
  [110]</I></DIV>
  <DIV><I><BR class=3Dwebkit-block-placeholder></I></DIV>
  <DIV><I>Lou&gt; ready for Last Call</I></DIV>
  <DIV><I>JP&gt; It sounds ready. Suggestion: offer IPSphere to have a =
look at=20
  the doc before last call. JP will be the point</I></DIV>
  <DIV><I>of contact. Asked Ross whether this is a good idea, and Ross =
agreed.=20
  Once comments are received, last call.</I></DIV>
  <DIV><I>Adrian&gt; OK, but this is not an indefinite consultation. We =
want to=20
  be able to move ahead and complete the I-D</I></DIV>
  <DIV><I>relatively soon.</I></DIV></DIV>
  <DIV><BR class=3Dwebkit-block-placeholder></DIV>
  <DIV>We have contacted IPSphere and RA WG of IPSphere should provide =
us some=20
  feed-back by</DIV>
  <DIV>mid-October. I have copied Tom Walsh and Christian Jacquenet =
(chair of=20
  the RAWG) IPSphere.</DIV>
  <DIV><BR class=3Dwebkit-block-placeholder></DIV>
  <DIV>Thanks.</DIV>
  <DIV><BR class=3Dwebkit-block-placeholder></DIV>
  <DIV>JP.</DIV></DIV>
  <DIV style=3D"MARGIN: =
0px">_______________________________________________</DIV>
  <DIV style=3D"MARGIN: 0px">Pce mailing list</DIV>
  <DIV style=3D"MARGIN: 0px"><A=20
  href=3D"mailto:Pce@lists.ietf.org">Pce@lists.ietf.org</A></DIV>
  <DIV style=3D"MARGIN: 0px"><A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/pce">https://www1.ietf.org=
/mailman/listinfo/pce</A></DIV></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML=
>

------_=_NextPart_001_01C80A6A.37D060F8--



--===============1595384019==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============1595384019==--





From pce-bounces@lists.ietf.org Thu Oct 11 08:10:22 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ifwrc-00086C-4v; Thu, 11 Oct 2007 08:10:04 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1Ifwrb-000867-7N
	for pce-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 08:10:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifwra-00085w-SI
	for pce@ietf.org; Thu, 11 Oct 2007 08:10:02 -0400
Received: from pythagoras.zen.co.uk ([212.23.3.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfwrT-0005oc-Rt
	for pce@ietf.org; Thu, 11 Oct 2007 08:10:02 -0400
Received: from [88.96.235.138] (helo=cortex.aria-networks.com)
	by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1IfwrM-0008Um-9h
	for pce@ietf.org; Thu, 11 Oct 2007 12:09:49 +0000
Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by
	cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Thu, 11 Oct 2007 13:09:46 +0100
Message-ID: <0c1001c80bff$99ff71c0$5102010a@your029b8cecfe>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "JACQUENET Christian RD-DDEV-REN" <christian.jacquenet@orange-ftgroup.com>
References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com><14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
	<8AA97249241F7148BE6D3D8B93D83F5A0F5FB42B@ftrdmel2>
Subject: Re: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
Date: Thu, 11 Oct 2007 13:09:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 11 Oct 2007 12:09:46.0856 (UTC)
	FILETIME=[9D973E80:01C80BFF]
X-Originating-Pythagoras-IP: [88.96.235.138]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc
Cc: gash5107@yahoo.com, Thomas Walsh <twalsh@juniper.net>, pce@ietf.org,
	Igor Bryskin <ibryskin@movaz.com>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Christian,

Many thanks for a good review and useful comments.

Can I assume that there are no further comments coming specifically from the 
IPSphere Forum?

Authors, can you tell me whether the scope of comments here are large enough 
to justify a new revision before working group last call? It seems to me 
that the answer should probably be "yes", but I'm open to persuasion.

Thanks,
Adrian

----- Original Message ----- 
From: "JACQUENET Christian RD-DDEV-REN" 
<christian.jacquenet@orange-ftgroup.com>
To: "JP Vasseur" <jvasseur@cisco.com>; <pce@ietf.org>; "Lou Berger" 
<lberger@labn.net>; "Igor Bryskin" <ibryskin@movaz.com>; "Dimitri 
Papadimitriou" <dpapadimitriou@psg.com>; <gash5107@yahoo.com>
Cc: "Thomas Walsh" <twalsh@juniper.net>
Sent: Tuesday, October 09, 2007 12:47 PM
Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp


Dear all,

Please find herein my comments, which are *not* on behalf of the IPSF - only 
personal :-)
1. General:

I think this is a very useful document that clearly identifies the 
advantages of policy-based path computation management in PCE environments. 
Nevertheless, I would encourage a refined organization of the document, 
which would distinguish between the framework (current sections 2.1, 4 and 5 
basically), the requirements (section 3, but also part of the text that 
relates to scenarios) and use cases or scenarios (sections 2.2.x, a bit of 
sections 7 and 8).

2. Section 2.1, page 5:

The introductory sentence of the third paragraph implicly indicates that PCE 
may very well behave as either a PDP (makes decisions to be applied by PCC 
clients for example) or a PEP (applies decisions possibly made by PCC 
clients and/or other PCE components). I think this is one of the very key 
notions introduced by this draft, and would therefore suggest an 
introductory section that would elaborate on this heuristic, possibly after 
the reminder about basic concepts of policy-based management.

3. Section 2.1, page 6:

The last sentence of the first paragraph is slightly confusing: I don't 
think the "or" is exclusive, that is, provider-defined policies might very 
well be real time.

4. Section 2.2.3, page 11:

What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP or both? 
I think this should be elaborated, possibly in the Terminology section. Note 
also that the last sentence of the page mixes the notions of "making 
decision" and "apply user or service-specific policies": since the text 
introduces a kind of causality effect (the PEP embedded in the PCC enforces 
user or service-specific policies, which seems to result in soliciting the 
PDP embedded in the PEP to make decisions about the scope of constraints 
that need to be taken into account for path computation purposes), I would 
suggest a kind of flow diagram that could possibly elaborate on the 
corresponding chronology.

5. Section 2.2.3, page 12:

Related to the comment above, the sentence "when deciding..." of the first 
paragraph may also suggest the activation of a LPDP capability. I would also 
elaborate on the possible interactions between the PEP, the PDP and the 
possible LPDP capabilities that may be embedded in the PCC, assuming a 
differentiation "a la COPS Client-Type". Who's the destinee of the path 
computation request in the "once the constraints..." sentence of the same 
paragraph - the PCE?

In the third paragraph, it seems that (1) The PCC embeds a PDP that makes 
decisions about constraint-defined policies, (2) Sends a path computation 
request that conveys the aforementioned policy information towards the PCE, 
whose embedded PEP (3) Applies the corresponding decisions: is this 
statement correct? If so, I don't understand why the PCE may "decide to 
reject the request": that is, from a policy management standpoint, only the 
PEP of the PCE is solicited in this context, which means that the PEP may 
not be capable of enforcing the decision, but I don't think the PEP is 
entitled to *reject* the decision, as part of a decision making process. 
Maybe it's a wording issue.

What would be the conditions to send path computation requests to more than 
one PCE, aside from an inter-domain context? I'm not sure I understand why 
the response sent by the PCE-PEP back to the requesting PCC-PDP may indicate 
*policies*. Unless the document refers to a kind of PCE-inferred feedback 
PIB (RFC 3571)? In that case, I would elaborate.

6. Section 3, page 15:

The notion of trusted nodes (as introdcued in the third paragraph) should 
deserve some elaboration, IMHO. The security considerations of this page 
should either be extended (e.g. preservation of the confidentiality of the 
information that will be exchanged between a PDP and a set of PDPs), or 
reference the "true" Security Considerations section of the document, which 
BTW, rightfully elaborates on such issues.

7. Section 5, page 18:

I don't understand why a protocol like COPS couldn't be used in the case 
where PEP and PDP are colocated. In any case, a protocol is required to 
convey the exchanges between the PEP and the PDP...

In addition (last line of the page), it's very unlikely that SNMP will be 
used to retrieve information from a PIB.

8. Section 5, page 19:

I would suggest some elaboration on the kind of information any given PEP 
(PCC or PCE) may receive from another *PEP* - is this a typo (i.e. read PDP 
instead), or does this relate to information different from "policy-related" 
information or else? In a COPS context, multiple Client-Types can certainly 
reside and coexist within a PEP, but I'm not sure I understand why PEPs 
would exchange information.

Also, the following paragraph ("any given policy...") is a bit confusing to 
me: I don't understand this notion of partial interpretation, and would 
rather suggest another wording - enforcement instead of interpretation. 
Besides, I'm not sure this paragraph helps in understanding the roles played 
by PEPs and PDPs.

9. Section 6.1., page 20:

Why *all* PC policy types used in the net *must* be applied? It's a 
"Client-Type" specific thing, IMHO.

10. Section 6.1., page 21:

In the first paragraph, I don't understand why the PCE selection should be 
static. Even if the policy enforcement is restricted to the PCE (for path 
computation purposes), nothing prevents a PEP embedded in a PCC to support 
the relevant "Client-Type", hence yielding the dynamic identification of the 
corresponding PCE, by means of the COPS-like OPEN message at PCC bootstrap, 
for example.

In the third paragraph, the "must" of the first sentence is too strong, 
IMHO, unless the sentence means that any kind of policy must "encouarge" the 
support of the corresponding "Client-Types" in the PCC-PEP. If so, I would 
rephrase.

11. Section 6.2., page 22:

I don't understand why matching repositories would result in a single PC 
repository, unless further elaboration on such match is provided.

12. Section 6.3, page 23:

Does the figure relate to PCE instead of PCC (same for figure 12)?

13. Section 7.1., page 25:

What's an "objection function"?

14. Typos:

TED = Traffic Engineering Database?

SRLG = Shared Risk Link Group?

Page 16, provide the normative reference associated to LDAPv3.

Page 17, remove the "s" of the very last word of the page.

Cheers,

Christian.


________________________________

De : JP Vasseur [mailto:jvasseur@cisco.com]
Envoyé : lundi 8 octobre 2007 22:36
À : pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri Papadimitriou; 
gash5107@yahoo.com
Cc : Thomas Walsh; JACQUENET Christian RD-DDEV-REN
Objet : Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp


Dear WG,

Christian Jacquenet on behalf of IPSphere proposed to make several comments 
on this document.
Christian, could you please send them to the list ?

As agreed, we're still planning to issue a WG LC after this round of 
discussion.

Thanks.

JP.


Begin forwarded message:


From: JP Vasseur <jvasseur@cisco.com>
Date: September 18, 2007 2:10:12 PM EDT
To: pce@ietf.org, Lou Berger <lberger@labn.net>, Igor Bryskin 
<ibryskin@movaz.com>, Dimitri Papadimitriou <dpapadimitriou@psg.com>, 
gash5107@yahoo.com
Cc: Thomas Walsh <twalsh@juniper.net>, JACQUENET Christian RD-TCH-REN 
<christian.jacquenet@francetelecom.com>
Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Dear WG,

>From the WG minutes of the IETF-69 meeting:


12) Update on Policy-Enabled Path Computation Framework
draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]


Lou> ready for Last Call
JP> It sounds ready. Suggestion: offer IPSphere to have a look at the doc 
before last call. JP will be the point
of contact. Asked Ross whether this is a good idea, and Ross agreed. Once 
comments are received, last call.
Adrian> OK, but this is not an indefinite consultation. We want to be able 
to move ahead and complete the I-D
relatively soon.

We have contacted IPSphere and RA WG of IPSphere should provide us some 
feed-back by
mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of the 
RAWG) IPSphere.

Thanks.

JP.




_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Thu Oct 11 11:14:15 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IfzjY-0004Xt-8y; Thu, 11 Oct 2007 11:13:56 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IfzjX-0004VB-0r
	for pce-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 11:13:55 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzjW-0004V1-KR
	for pce@ietf.org; Thu, 11 Oct 2007 11:13:54 -0400
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfzjV-0001QF-Ce
	for pce@ietf.org; Thu, 11 Oct 2007 11:13:54 -0400
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by
	ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 11 Oct 2007 17:13:47 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
Date: Thu, 11 Oct 2007 17:13:33 +0200
Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0F62CBA4@ftrdmel2>
In-Reply-To: <0c1001c80bff$99ff71c0$5102010a@your029b8cecfe>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
Thread-Index: AcgMALaakhvoK8jkRuqvIKBsAA+cqwAGG79g
References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com><14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
	<8AA97249241F7148BE6D3D8B93D83F5A0F5FB42B@ftrdmel2>
	<0c1001c80bff$99ff71c0$5102010a@your029b8cecfe>
From: "JACQUENET Christian RD-DDEV-REN"
	<christian.jacquenet@orange-ftgroup.com>
To: <adrian@olddog.co.uk>
X-OriginalArrivalTime: 11 Oct 2007 15:13:47.0448 (UTC)
	FILETIME=[524BE380:01C80C19]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798
Cc: rawg@ipsphereforum.org, gash5107@yahoo.com,
	Thomas Walsh <twalsh@juniper.net>, pce@ietf.org,
	Igor Bryskin <ibryskin@movaz.com>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Adrian,

Pleasure's all mine :-) Don't expect further comments from the "IPSF", =
but I'll let individuals who are also involved in the IPSF comment =
further if they want to.

Cheers,

Christian.=20

-----Message d'origine-----
De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20
Envoy=E9 : jeudi 11 octobre 2007 14:10
=C0 : JACQUENET Christian RD-DDEV-REN
Cc : Thomas Walsh; JP Vasseur; pce@ietf.org; Lou Berger; Igor Bryskin; =
Dimitri Papadimitriou; gash5107@yahoo.com
Objet : Re: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Christian,

Many thanks for a good review and useful comments.

Can I assume that there are no further comments coming specifically from =
the IPSphere Forum?

Authors, can you tell me whether the scope of comments here are large =
enough to justify a new revision before working group last call? It =
seems to me that the answer should probably be "yes", but I'm open to =
persuasion.

Thanks,
Adrian

----- Original Message -----
From: "JACQUENET Christian RD-DDEV-REN"=20
<christian.jacquenet@orange-ftgroup.com>
To: "JP Vasseur" <jvasseur@cisco.com>; <pce@ietf.org>; "Lou Berger"=20
<lberger@labn.net>; "Igor Bryskin" <ibryskin@movaz.com>; "Dimitri =
Papadimitriou" <dpapadimitriou@psg.com>; <gash5107@yahoo.com>
Cc: "Thomas Walsh" <twalsh@juniper.net>
Sent: Tuesday, October 09, 2007 12:47 PM
Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp


Dear all,

Please find herein my comments, which are *not* on behalf of the IPSF - =
only personal :-) 1. General:

I think this is a very useful document that clearly identifies the =
advantages of policy-based path computation management in PCE =
environments.=20
Nevertheless, I would encourage a refined organization of the document, =
which would distinguish between the framework (current sections 2.1, 4 =
and 5 basically), the requirements (section 3, but also part of the text =
that relates to scenarios) and use cases or scenarios (sections 2.2.x, a =
bit of sections 7 and 8).

2. Section 2.1, page 5:

The introductory sentence of the third paragraph implicly indicates that =
PCE may very well behave as either a PDP (makes decisions to be applied =
by PCC clients for example) or a PEP (applies decisions possibly made by =
PCC clients and/or other PCE components). I think this is one of the =
very key notions introduced by this draft, and would therefore suggest =
an introductory section that would elaborate on this heuristic, possibly =
after the reminder about basic concepts of policy-based management.

3. Section 2.1, page 6:

The last sentence of the first paragraph is slightly confusing: I don't =
think the "or" is exclusive, that is, provider-defined policies might =
very well be real time.

4. Section 2.2.3, page 11:

What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP or =
both?=20
I think this should be elaborated, possibly in the Terminology section. =
Note also that the last sentence of the page mixes the notions of =
"making decision" and "apply user or service-specific policies": since =
the text introduces a kind of causality effect (the PEP embedded in the =
PCC enforces user or service-specific policies, which seems to result in =
soliciting the PDP embedded in the PEP to make decisions about the scope =
of constraints that need to be taken into account for path computation =
purposes), I would suggest a kind of flow diagram that could possibly =
elaborate on the corresponding chronology.

5. Section 2.2.3, page 12:

Related to the comment above, the sentence "when deciding..." of the =
first paragraph may also suggest the activation of a LPDP capability. I =
would also elaborate on the possible interactions between the PEP, the =
PDP and the possible LPDP capabilities that may be embedded in the PCC, =
assuming a differentiation "a la COPS Client-Type". Who's the destinee =
of the path computation request in the "once the constraints..." =
sentence of the same paragraph - the PCE?

In the third paragraph, it seems that (1) The PCC embeds a PDP that =
makes decisions about constraint-defined policies, (2) Sends a path =
computation request that conveys the aforementioned policy information =
towards the PCE, whose embedded PEP (3) Applies the corresponding =
decisions: is this statement correct? If so, I don't understand why the =
PCE may "decide to reject the request": that is, from a policy =
management standpoint, only the PEP of the PCE is solicited in this =
context, which means that the PEP may not be capable of enforcing the =
decision, but I don't think the PEP is entitled to *reject* the =
decision, as part of a decision making process.=20
Maybe it's a wording issue.

What would be the conditions to send path computation requests to more =
than one PCE, aside from an inter-domain context? I'm not sure I =
understand why the response sent by the PCE-PEP back to the requesting =
PCC-PDP may indicate *policies*. Unless the document refers to a kind of =
PCE-inferred feedback PIB (RFC 3571)? In that case, I would elaborate.

6. Section 3, page 15:

The notion of trusted nodes (as introdcued in the third paragraph) =
should deserve some elaboration, IMHO. The security considerations of =
this page should either be extended (e.g. preservation of the =
confidentiality of the information that will be exchanged between a PDP =
and a set of PDPs), or reference the "true" Security Considerations =
section of the document, which BTW, rightfully elaborates on such =
issues.

7. Section 5, page 18:

I don't understand why a protocol like COPS couldn't be used in the case =
where PEP and PDP are colocated. In any case, a protocol is required to =
convey the exchanges between the PEP and the PDP...

In addition (last line of the page), it's very unlikely that SNMP will =
be used to retrieve information from a PIB.

8. Section 5, page 19:

I would suggest some elaboration on the kind of information any given =
PEP (PCC or PCE) may receive from another *PEP* - is this a typo (i.e. =
read PDP instead), or does this relate to information different from =
"policy-related"=20
information or else? In a COPS context, multiple Client-Types can =
certainly reside and coexist within a PEP, but I'm not sure I understand =
why PEPs would exchange information.

Also, the following paragraph ("any given policy...") is a bit confusing =
to
me: I don't understand this notion of partial interpretation, and would =
rather suggest another wording - enforcement instead of interpretation.=20
Besides, I'm not sure this paragraph helps in understanding the roles =
played by PEPs and PDPs.

9. Section 6.1., page 20:

Why *all* PC policy types used in the net *must* be applied? It's a =
"Client-Type" specific thing, IMHO.

10. Section 6.1., page 21:

In the first paragraph, I don't understand why the PCE selection should =
be static. Even if the policy enforcement is restricted to the PCE (for =
path computation purposes), nothing prevents a PEP embedded in a PCC to =
support the relevant "Client-Type", hence yielding the dynamic =
identification of the corresponding PCE, by means of the COPS-like OPEN =
message at PCC bootstrap, for example.

In the third paragraph, the "must" of the first sentence is too strong, =
IMHO, unless the sentence means that any kind of policy must "encouarge" =
the support of the corresponding "Client-Types" in the PCC-PEP. If so, I =
would rephrase.

11. Section 6.2., page 22:

I don't understand why matching repositories would result in a single PC =
repository, unless further elaboration on such match is provided.

12. Section 6.3, page 23:

Does the figure relate to PCE instead of PCC (same for figure 12)?

13. Section 7.1., page 25:

What's an "objection function"?

14. Typos:

TED =3D Traffic Engineering Database?

SRLG =3D Shared Risk Link Group?

Page 16, provide the normative reference associated to LDAPv3.

Page 17, remove the "s" of the very last word of the page.

Cheers,

Christian.


________________________________

De : JP Vasseur [mailto:jvasseur@cisco.com] Envoy=E9 : lundi 8 octobre =
2007 22:36 =C0 : pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri =
Papadimitriou; gash5107@yahoo.com Cc : Thomas Walsh; JACQUENET Christian =
RD-DDEV-REN Objet : Fwd: [Pce] Update on =
draft-ietf-pce-policy-enabled-path-comp


Dear WG,

Christian Jacquenet on behalf of IPSphere proposed to make several =
comments=20
on this document.
Christian, could you please send them to the list ?

As agreed, we're still planning to issue a WG LC after this round of=20
discussion.

Thanks.

JP.


Begin forwarded message:


From: JP Vasseur <jvasseur@cisco.com>
Date: September 18, 2007 2:10:12 PM EDT
To: pce@ietf.org, Lou Berger <lberger@labn.net>, Igor Bryskin=20
<ibryskin@movaz.com>, Dimitri Papadimitriou <dpapadimitriou@psg.com>,=20
gash5107@yahoo.com
Cc: Thomas Walsh <twalsh@juniper.net>, JACQUENET Christian RD-TCH-REN=20
<christian.jacquenet@francetelecom.com>
Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp

Dear WG,

>From the WG minutes of the IETF-69 meeting:


12) Update on Policy-Enabled Path Computation Framework
draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]


Lou> ready for Last Call
JP> It sounds ready. Suggestion: offer IPSphere to have a look at the =
doc=20
before last call. JP will be the point
of contact. Asked Ross whether this is a good idea, and Ross agreed. =
Once=20
comments are received, last call.
Adrian> OK, but this is not an indefinite consultation. We want to be =
able=20
to move ahead and complete the I-D
relatively soon.

We have contacted IPSphere and RA WG of IPSphere should provide us some=20
feed-back by
mid-October. I have copied Tom Walsh and Christian Jacquenet (chair of =
the=20
RAWG) IPSphere.

Thanks.

JP.




_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Fri Oct 12 08:04:26 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IgJEX-0004kl-8f; Fri, 12 Oct 2007 08:03:13 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IfzeS-0000VX-Ju
	for pce-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 11:08:40 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzeS-0000SK-7y
	for pce@ietf.org; Thu, 11 Oct 2007 11:08:40 -0400
Received: from guadiana.unex.es ([158.49.17.23])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfzeO-0001CX-MA
	for pce@ietf.org; Thu, 11 Oct 2007 11:08:37 -0400
Received: from [158.49.122.70] (unknown [158.49.122.70])
	by guadiana.unex.es (Postfix) with ESMTP id 0E9251FDD2;
	Thu, 11 Oct 2007 17:08:22 +0200 (CEST)
Message-ID: <470E3C66.8080300@unex.es>
Date: Thu, 11 Oct 2007 17:08:22 +0200
From: Manuel Dominguez Dorado <mdomdor@unex.es>
Organization: University of Extremadura
User-Agent: Thunderbird 2.0.0.5 (X11/20070727)
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
Subject: Re: [Pce] Loops in path computation
References: <470E03A6.2010309@unex.es>
	<0bdc01c80bfc$d3d624f0$5102010a@your029b8cecfe>
In-Reply-To: <0bdc01c80bfc$d3d624f0$5102010a@your029b8cecfe>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
X-Mailman-Approved-At: Fri, 12 Oct 2007 08:03:12 -0400
Cc: 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mdomdor@unex.es
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

 > I assume you mean how to avoid loops created by re-entering a domain

Exact!

 > So far, little attention has been given to the selection of the
 > sequence of domains to be crossed by an inter-domain path. Although it
 > is recognised as a potential element to computation techniques it is
 > also  known that initial deployments will be severely gated by
 > administrative and commercial limitations (e.g., inter-AS peering
 > agreements) such that the sequence of domains for a path will be known
 > in advance.

OK. That is the answer I was looking for.

 > And, of course, if you apply the per-domain approach, the sequence of
 > domains is also known in advance.

Well, at the moment I am considering every approach. Although the=20
per-domain approach doesn't is affected by loops, I still need to carry=20
out a very detailed analysis to elaborate a cost/benefits report.

Thanks again.


------------------------------------------------------------------------
                         MANUEL DOM=CDNGUEZ DORADO
------------------------------------------------------------------------
Addr.: Laboratorio de Ingenier=ED=ADa Telem=E1tica
        Escuela Polit=E9cnica de C=E1ceres
        =C1rea de Ingenier=ED=ADa Telem=E1tica
        Departamento de Ingenier=ED=ADa de Sistemas Inform=E1ticos y Tele=
m=E1ticos
        Universidad de Extremadura
        Avda. de la Universidad s/n. 10071 - C=E1ceres - SPAIN
Phone: +34 607 417 860
Fax..: +34 927 257 202
Email: mdomdor@unex.es
Web.:: http://gitaca.unex.es/manolodd
------------------------------------------------------------------------



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Fri Oct 12 17:26:42 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IgS0f-000890-Sx; Fri, 12 Oct 2007 17:25:29 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IgS0e-0007zY-LU
	for pce-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 17:25:28 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IgS0e-0007w9-8R
	for pce@ietf.org; Fri, 12 Oct 2007 17:25:28 -0400
Received: from esc91.midphase.com ([216.104.33.66])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgS0d-0008Li-6S
	for pce@ietf.org; Fri, 12 Oct 2007 17:25:28 -0400
Received: from esc91.midphase.com ([216.104.33.66] helo=LC1.labn.net)
	by esc91.midphase.com with esmtpa (Exim 4.68)
	(envelope-from <lberger@labn.net>)
	id 1IgS0W-0005Qv-Im; Fri, 12 Oct 2007 17:25:20 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Oct 2007 17:25:07 -0400
To: "JACQUENET Christian RD-DDEV-REN" <christian.jacquenet@orange-ftgroup.com>
From: Lou Berger <lberger@labn.net>
Subject: RE: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
In-Reply-To: <8AA97249241F7148BE6D3D8B93D83F5A0F5FB42B@ftrdmel2>
References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com>
	<14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
	<8AA97249241F7148BE6D3D8B93D83F5A0F5FB42B@ftrdmel2>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc91.midphase.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 1.8 (+)
X-Scan-Signature: c2e58d9873012c90703822e287241385
Message-Id: <E1IgS0e-0007zY-LU@megatron.ietf.org>
Cc: gash5107@yahoo.com, Thomas Walsh <twalsh@juniper.net>, pce@ietf.org,
	Igor Bryskin <ibryskin@movaz.com>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Christian,
         Much thanks for the detailed=20
comments.  We'll incorporate changes in the next rev.

BTW one theme in your comments seems to come for=20
the style of section 2 staying at a higher level=20
(trying to focus on what can be done) and the=20
later sections getting into more of the details,=20
e.g., PEP and PDP functions.  This approach was=20
intentional and I'd be surprised if the next rev=20
radically departs from this.  That said, I think=20
you have many good comments which will result in=20
a more readable document once addressed.

Thanks again for the input,
Lou


At 07:47 AM 10/9/2007, JACQUENET Christian RD-DDEV-REN wrote:

>Dear all,
>
>Please find herein my comments, which are *not*=20
>on behalf of the IPSF - only personal :-)
>
>1. General:
>I think this is a very useful document that=20
>clearly identifies the advantages of=20
>policy-based path computation management in PCE=20
>environments. Nevertheless, I would encourage a=20
>refined organization of the document, which=20
>would distinguish between the framework (current=20
>sections 2.1, 4 and 5 basically), the=20
>requirements (section 3, but also part of the=20
>text that relates to scenarios) and use cases or=20
>scenarios (sections 2.2.x, a bit of sections 7 and 8).
>
>2. Section 2.1, page 5:
>The introductory sentence of the third paragraph=20
>implicly indicates that PCE may very well behave=20
>as either a PDP (makes decisions to be applied=20
>by PCC clients for example) or a PEP (applies=20
>decisions possibly made by PCC clients and/or=20
>other PCE components). I think this is one of=20
>the very key notions introduced by this draft,=20
>and would therefore suggest an introductory=20
>section that would elaborate on this heuristic,=20
>possibly after the reminder about basic concepts of policy-based=
 management.
>
>3. Section 2.1, page 6:
>The last sentence of the first paragraph is=20
>slightly confusing: I don't think the "or" is=20
>exclusive, that is, provider-defined policies might very well be real time.
>
>4. Section 2.2.3, page 11:
>What's a policy-enabled PCC? A PCC that either=20
>embeds a PEP, a PDP or both? I think this should=20
>be elaborated, possibly in the Terminology=20
>section. Note also that the last sentence of the=20
>page mixes the notions of "making decision" and=20
>"apply user or service-specific policies": since=20
>the text introduces a kind of causality effect=20
>(the PEP embedded in the PCC enforces user or=20
>service-specific policies, which seems to result=20
>in soliciting the PDP embedded in the PEP to=20
>make decisions about the scope of constraints=20
>that need to be taken into account for path=20
>computation purposes), I would suggest a kind of=20
>flow diagram that could possibly elaborate on the corresponding chronology.
>
>5. Section 2.2.3, page 12:
>Related to the comment above, the sentence "when=20
>deciding=85" of the first paragraph may also=20
>suggest the activation of a LPDP capability. I=20
>would also elaborate on the possible=20
>interactions between the PEP, the PDP and the=20
>possible LPDP capabilities that may be embedded=20
>in the PCC, assuming a differentiation "a la=20
>COPS Client-Type". Who's the destinee of the=20
>path computation request in the "once the=20
>constraints=85" sentence of the same paragraph -=20
>the PCE? In the third paragraph, it seems that=20
>(1) The PCC embeds a PDP that makes decisions=20
>about constraint-defined policies, (2) Sends a=20
>path computation request that conveys the=20
>aforementioned policy information towards the=20
>PCE, whose embedded PEP (3) Applies the=20
>corresponding decisions: is this statement=20
>correct? If so, I don't understand why the PCE=20
>may "decide to reject the request": that is,=20
>from a policy management standpoint, only the=20
>PEP of the PCE is solicited in this context,=20
>which means that the PEP may not be capable of=20
>enforcing the decision, but I don't think the=20
>PEP is entitled to *reject* the decision, as=20
>part of a decision making process. Maybe it's a=20
>wording issue. What would be the conditions to=20
>send path computation requests to more than one=20
>PCE, aside from an inter-domain context? I'm not=20
>sure I understand why the response sent by the=20
>PCE-PEP back to the requesting PCC-PDP may=20
>indicate *policies*. Unless the document refers=20
>to a kind of PCE-inferred feedback PIB (RFC=20
>3571)? In that case, I would elaborate.
>
>6. Section 3, page 15:
>The notion of trusted nodes (as introdcued in=20
>the third paragraph) should deserve some=20
>elaboration, IMHO. The security considerations=20
>of this page should either be extended (e.g.=20
>preservation of the confidentiality of the=20
>information that will be exchanged between a PDP=20
>and a set of PDPs), or reference the "true"=20
>Security Considerations section of the document,=20
>which BTW, rightfully elaborates on such issues.
>
>7. Section 5, page 18:
>I don't understand why a protocol like COPS=20
>couldn't be used in the case where PEP and PDP=20
>are colocated. In any case, a protocol is=20
>required to convey the exchanges between the PEP=20
>and the PDP=85 In addition (last line of the=20
>page), it's very unlikely that SNMP will be used=20
>to retrieve information from a PIB.
>
>8. Section 5, page 19:
>I would suggest some elaboration on the kind of=20
>information any given PEP (PCC or PCE) may=20
>receive from another *PEP* - is this a typo=20
>(i.e. read PDP instead), or does this relate to=20
>information different from "policy-related"=20
>information or else? In a COPS context, multiple=20
>Client-Types can certainly reside and coexist=20
>within a PEP, but I'm not sure I understand why=20
>PEPs would exchange information. Also, the=20
>following paragraph ("any given policy=85") is a=20
>bit confusing to me: I don't understand this=20
>notion of partial interpretation, and would=20
>rather suggest another wording - enforcement=20
>instead of interpretation. Besides, I'm not sure=20
>this paragraph helps in understanding the roles played by PEPs and PDPs.
>
>9. Section 6.1., page 20:
>Why *all* PC policy types used in the net *must*=20
>be applied? It's a "Client-Type" specific thing, IMHO.
>
>10. Section 6.1., page 21:
>In the first paragraph, I don't understand why=20
>the PCE selection should be static. Even if the=20
>policy enforcement is restricted to the PCE (for=20
>path computation purposes), nothing prevents a=20
>PEP embedded in a PCC to support the relevant=20
>"Client-Type", hence yielding the dynamic=20
>identification of the corresponding PCE, by=20
>means of the COPS-like OPEN message at PCC=20
>bootstrap, for example. In the third paragraph,=20
>the "must" of the first sentence is too strong,=20
>IMHO, unless the sentence means that any kind of=20
>policy must "encouarge" the support of the=20
>corresponding "Client-Types" in the PCC-PEP. If so, I would rephrase.
>
>11. Section 6.2., page 22:
>I don't understand why matching repositories=20
>would result in a single PC repository, unless=20
>further elaboration on such match is provided.
>
>12. Section 6.3, page 23:
>Does the figure relate to PCE instead of PCC (same for figure 12)?
>
>13. Section 7.1., page 25:
>What's an "objection function"?
>
>14. Typos:
>TED =3D Traffic Engineering Database? SRLG =3D=20
>Shared Risk Link Group? Page 16, provide the=20
>normative reference associated to LDAPv3. Page=20
>17, remove the "s" of the very last word of the page.
>
>Cheers,
>
>Christian.
>
>
>----------
>De : JP Vasseur [mailto:jvasseur@cisco.com]
>Envoy=E9 : lundi 8 octobre 2007 22:36
>=C0 : pce@ietf.org; Lou Berger; Igor Bryskin;=20
>Dimitri Papadimitriou; gash5107@yahoo.com
>Cc : Thomas Walsh; JACQUENET Christian RD-DDEV-REN
>Objet : Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
>
>Dear WG,
>
>Christian Jacquenet on behalf of IPSphere=20
>proposed to make several comments on this document.
>Christian, could you please send them to the list ?
>
>As agreed, we're still planning to issue a WG LC=20
>after this round of discussion.
>
>Thanks.
>
>JP.
>
>Begin forwarded message:
>
>>From: JP Vasseur <<mailto:jvasseur@cisco.com>jvasseur@cisco.com>
>>Date: September 18, 2007 2:10:12 PM EDT
>>To: <mailto:pce@ietf.org>pce@ietf.org, Lou=20
>>Berger=20
>><<mailto:lberger@labn.net>lberger@labn.net>,=20
>>Igor Bryskin=20
>><<mailto:ibryskin@movaz.com>ibryskin@movaz.com>,=20
>>  Dimitri Papadimitriou=20
>><<mailto:dpapadimitriou@psg.com>dpapadimitriou@psg.com>,=20
>><mailto:gash5107@yahoo.com>gash5107@yahoo.com
>>Cc: Thomas Walsh=20
>><<mailto:twalsh@juniper.net>twalsh@juniper.net>,=20
>>  JACQUENET Christian RD-TCH-REN=20
>><<mailto:christian.jacquenet@francetelecom.com>christian.jacquenet@francet=
elecom.com>
>>Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
>>
>>Dear WG,
>>
>> From the WG minutes of the IETF-69 meeting:
>>
>>12) Update on Policy-Enabled Path Computation Framework
>>draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]
>>
>>Lou> ready for Last Call
>>JP> It sounds ready. Suggestion: offer IPSphere=20
>>to have a look at the doc before last call. JP will be the point
>>of contact. Asked Ross whether this is a good=20
>>idea, and Ross agreed. Once comments are received, last call.
>>Adrian> OK, but this is not an indefinite=20
>>consultation. We want to be able to move ahead and complete the I-D
>>relatively soon.
>>
>>We have contacted IPSphere and RA WG of=20
>>IPSphere should provide us some feed-back by
>>mid-October. I have copied Tom Walsh and=20
>>Christian Jacquenet (chair of the RAWG) IPSphere.
>>
>>Thanks.
>>
>>JP.
>>_______________________________________________
>>Pce mailing list
>><mailto:Pce@lists.ietf.org>Pce@lists.ietf.org
>>https://www1.ietf.org/mailman/listinfo/pce



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Fri Oct 12 17:36:38 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IgSB5-0004nw-NK; Fri, 12 Oct 2007 17:36:15 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IgSB3-0004mJ-2c
	for pce-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 17:36:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IgSB2-0004lY-Oq
	for pce@ietf.org; Fri, 12 Oct 2007 17:36:12 -0400
Received: from esc91.midphase.com ([216.104.33.66])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgSAx-0005nM-IJ
	for pce@ietf.org; Fri, 12 Oct 2007 17:36:12 -0400
Received: from esc91.midphase.com ([216.104.33.66] helo=LC1.labn.net)
	by esc91.midphase.com with esmtpa (Exim 4.68)
	(envelope-from <lberger@labn.net>)
	id 1IgSAd-0007tu-V4; Fri, 12 Oct 2007 17:35:48 -0400
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 12 Oct 2007 17:34:18 -0400
To: "Adrian Farrel" <adrian@olddog.co.uk>
From: Lou Berger <lberger@labn.net>
Subject: Re: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
In-Reply-To: <0c1001c80bff$99ff71c0$5102010a@your029b8cecfe>
References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com>
	<14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
	<8AA97249241F7148BE6D3D8B93D83F5A0F5FB42B@ftrdmel2>
	<0c1001c80bff$99ff71c0$5102010a@your029b8cecfe>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc91.midphase.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Message-Id: <E1IgSB3-0004mJ-2c@megatron.ietf.org>
Cc: gash5107@yahoo.com, Igor Bryskin <IBryskin@advaoptical.com>,
	Thomas Walsh <twalsh@juniper.net>, pce@ietf.org,
	JACQUENET Christian RD-DDEV-REN <christian.jacquenet@orange-ftgroup.com>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

At 08:09 AM 10/11/2007, Adrian Farrel wrote:
>[...]
>Authors, can you tell me whether the scope of comments here are 
>large enough to justify a new revision before working group last 
>call? It seems to me that the answer should probably be "yes", but 
>I'm open to persuasion.
>[...]

Adrian,
         Speaking only for myself and not my co-authors, I don't 
believe addressing the comments will result in any substantive 
changes.  That said, the resulting document should be more 
readable.  If we wait for the last call, we can probably have a rev 
out in the first week of November.

I have slight preference for doing a last call now so we can find out 
if there are any more substantive issues that need to be 
addressed.  But, it's your call if you want to wait.

Lou



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Sat Oct 13 12:48:06 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Igk7w-00026j-5p; Sat, 13 Oct 2007 12:46:12 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1Igk7u-00020m-GZ
	for pce-confirm+ok@megatron.ietf.org; Sat, 13 Oct 2007 12:46:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Igk7u-00020Y-6d
	for pce@ietf.org; Sat, 13 Oct 2007 12:46:10 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Igk7n-0002HR-JT
	for pce@ietf.org; Sat, 13 Oct 2007 12:46:10 -0400
X-IronPort-AV: E=Sophos;i="4.21,271,1188802800"; 
	d="scan'208,217";a="180802717"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-5.cisco.com with ESMTP; 13 Oct 2007 09:45:58 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9DGjv13030344
	for <pce@ietf.org>; Sat, 13 Oct 2007 09:45:57 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9DGjvsZ027936
	for <pce@ietf.org>; Sat, 13 Oct 2007 16:45:57 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 13 Oct 2007 09:45:57 -0700
Received: from [192.168.50.180] ([10.21.123.166]) by
	xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 13 Oct 2007 09:45:56 -0700
Mime-Version: 1.0 (Apple Message framework v752.2)
To: pce@ietf.org
Message-Id: <5467F885-46E4-43EA-9B7D-E61AB261C214@cisco.com>
References: <E1IgMhA-00025Z-OI@ietf.org>
From: JP Vasseur <jvasseur@cisco.com>
Date: Sat, 13 Oct 2007 16:29:53 +0200
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 13 Oct 2007 16:45:57.0084 (UTC)
	FILETIME=[870AE1C0:01C80DB8]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14228; t=1192293957;
	x=1193157957; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jvasseur@cisco.com;
	z=From:=20JP=20Vasseur=20<jvasseur@cisco.com>
	|Subject:=20Fwd=3A=20REVISED=20Internet-Draft=20Submission=20Cutoff=20Dat
	es=20for=20the=2070th=20IETF=20=20Meeting=20in=20Vancouver, =20BC,
	=20Canada =20 |Sender:=20;
	bh=NXw58K7orlw1tI9fZxGG2EUSxlSOUC0GlqCYEvere5Y=;
	b=qa4UETkqNO3TIwgxu31Znn0MjUuF9jRzYYdHiMwjrVqPo8rCAqFdgENXBfs9o/5CfCqg9meb
	CRazij9J1aP+pkZX+5ZYF0lhzUq1yDZJLC7GmIhuzNOsDJY/vcEdk0hQ;
Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e
Cc: 
Subject: [Pce] Fwd: REVISED Internet-Draft Submission Cutoff Dates for the
	70th IETF Meeting in Vancouver, BC, Canada 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0131712323=="
Errors-To: pce-bounces@lists.ietf.org


--===============0131712323==
Content-Type: multipart/alternative; boundary=Apple-Mail-9--769771457


--Apple-Mail-9--769771457
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed



Begin forwarded message:

> From: IETF Secretariat <ietf-secretariat@ietf.org>
> Date: October 12, 2007 5:45:00 PM CEDT
> To: IETF Announcement list <ietf-announce@ietf.org>
> Subject: REVISED Internet-Draft Submission Cutoff Dates for the  
> 70th IETF  Meeting in Vancouver, BC, Canada
>
> There are two (2) Internet-Draft cutoff dates for the 70th IETF
> Meeting in Vancouver, BC, Canada:
>
> November 12th: Cutoff Date for Initial (i.e., version -00) Internet- 
> Draft
> Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> November 12th at 9:00 AM ET (14:00 UTC/GMT). The only exception is for
> version -00 WG drafts that replace existing non-WG drafts.  Such  
> drafts
> may be submitted until the cutoff date for version -01 and higher  
> drafts.
> As always, all initial submissions with a filename beginning with
> "draft-ietf" must be approved by the appropriate WG Chair before  
> they can
> be processed or announced.  The Secretariat would appreciate  
> receiving WG
> Chair approval by Monday, November 5th at 9:00 AM ET (14:00 UTC/GMT).
>
> November 19th: Cutoff Date for Revised (i.e., version -01 and higher)
> Internet-Draft Submissions
>
> All revised Internet-Drafts (version -01 and higher) must be  
> submitted by
> Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT).
>
> Initial and revised Internet-Drafts submitted after their respective
> cutoff dates will not be made available in the Internet-Drafts  
> directory
> or announced until on or after Monday, December 3rd at 9:00 AM ET  
> (14:00
> UTC/GMT), when Internet-Draft posting resumes.  Please do not wait  
> until
> the last minute to submit.
>
> The Secretariat encourages you to submit your Internet-Drafts via the
> Internet-Draft Submission Tool (IDST)
> https://datatracker.ietf.org/idst/upload.cgi. If you are unable to  
> do so,
> then you may still submit your Internet-Drafts manually by sending  
> them to
> internet-drafts@ietf.org.  If you are submitting a version -00 WG  
> draft
> that replaces non-WG draft, then you must submit it manually as the
> current IDST cannot handle replacements.  Please be sure to state  
> that one
> draft replaces another in the cover note that accompanies your
> submission.  Also, please note that the IDST will not accept drafts
> submitted after their respective cutoff dates.
>
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> internet-drafts@ietf.org.
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant  
> dates
> for the 70th IETF Meeting can be found at
> http://www3.ietf.org/meetings/70-cutoff_dates.html.
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce


--Apple-Mail-9--769771457
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">
<br><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px =
Helvetica">IETF Secretariat &lt;<a =
href=3D"mailto:ietf-secretariat@ietf.org">ietf-secretariat@ietf.org</a>&gt=
;</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>Date: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica">October 12, 2007 5:45:00 PM =
CEDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica">IETF Announcement list &lt;<a =
href=3D"mailto:ietf-announce@ietf.org">ietf-announce@ietf.org</a>&gt;</fon=
t></div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" =
color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica"><b>REVISED Internet-Draft Submission =
Cutoff Dates for the 70th IETF<span class=3D"Apple-converted-space">=A0 =
</span>Meeting in Vancouver, BC, Canada<span =
class=3D"Apple-converted-space">=A0</span></b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div> <div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">There =
are two (2) Internet-Draft cutoff dates for the 70th IETF<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Meeting =
in Vancouver, BC, Canada:</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">November 12th: Cutoff Date for =
Initial (i.e., version -00) Internet-Draft</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Submissions<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">All =
initial Internet-Drafts (version -00) must be submitted by =
Monday,</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">November 12th at 9:00 AM ET =
(14:00 UTC/GMT). The only exception is for</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">version =
-00 WG drafts that replace existing non-WG drafts.<span =
class=3D"Apple-converted-space">=A0 </span>Such drafts</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">may be submitted until the cutoff date for version =
-01 and higher drafts.</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">As always, all initial =
submissions with a filename beginning with</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">"draft-ietf" must be approved by the appropriate WG Chair before they =
can</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">be processed or announced.<span =
class=3D"Apple-converted-space">=A0 </span>The Secretariat would =
appreciate receiving WG</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Chair =
approval by Monday, November 5th at 9:00 AM ET (14:00 =
UTC/GMT).</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">November 19th: Cutoff Date for Revised (i.e., =
version -01 and higher)</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Internet-Draft Submissions<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">All revised =
Internet-Drafts (version -01 and higher) must be submitted by</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Monday, November 19th at 9:00 AM ET (14:00 =
UTC/GMT).</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Initial and revised Internet-Drafts submitted after =
their respective</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">cutoff dates will not be made =
available in the Internet-Drafts directory</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">or =
announced until on or after Monday, December 3rd at 9:00 AM ET =
(14:00</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">UTC/GMT), when Internet-Draft =
posting resumes.<span class=3D"Apple-converted-space">=A0 </span>Please =
do not wait until</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">the last minute to =
submit.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">The Secretariat encourages you to submit your =
Internet-Drafts via the</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Internet-Draft Submission Tool (IDST)</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"https://datatracker.ietf.org/idst/upload.cgi">https://datatracker.=
ietf.org/idst/upload.cgi</a>. If you are unable to do so,</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">then you may still submit your Internet-Drafts =
manually by sending them to</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>.<spa=
n class=3D"Apple-converted-space">=A0 </span>If you are submitting a =
version -00 WG draft</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">that replaces non-WG draft, =
then you must submit it manually as the</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">current =
IDST cannot handle replacements.<span class=3D"Apple-converted-space">=A0 =
</span>Please be sure to state that one</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">draft =
replaces another in the cover note that accompanies your<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">submission.<span class=3D"Apple-converted-space">=A0 </span>Also, =
please note that the IDST will not accept drafts</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">submitted after their respective cutoff =
dates.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Thank you for your understanding and cooperation. If =
you have any</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">questions or concerns, then =
please send a message to</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>.</di=
v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The IETF =
Secretariat</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">FYI: The Internet-Draft cutoff dates as well as =
other significant dates</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">for the 70th =
IETF Meeting can be found at</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"http://www3.ietf.org/meetings/70-cutoff_dates.html">http://www3.ie=
tf.org/meetings/70-cutoff_dates.html</a>.</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"mailto:IETF-Announce@ietf.org">IETF-Announce@ietf.org</a></div><di=
v style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</a></div> =
</blockquote></div><br></body></html>=

--Apple-Mail-9--769771457--



--===============0131712323==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============0131712323==--





From pce-bounces@lists.ietf.org Sun Oct 14 08:25:43 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ih2Vn-0001Qc-QY; Sun, 14 Oct 2007 08:24:03 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1Ih2Vm-0001Nz-2b
	for pce-confirm+ok@megatron.ietf.org; Sun, 14 Oct 2007 08:24:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih2Vl-0001Nr-PA
	for pce@ietf.org; Sun, 14 Oct 2007 08:24:01 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ih2Vf-0002I4-Gc
	for pce@ietf.org; Sun, 14 Oct 2007 08:24:01 -0400
X-IronPort-AV: E=Sophos;i="4.21,273,1188792000"; d="scan'208";a="134885116"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2007 08:23:39 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9ECNeRK006105; 
	Sun, 14 Oct 2007 08:23:40 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9ECNLk7004731; 
	Sun, 14 Oct 2007 12:23:21 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 14 Oct 2007 08:23:20 -0400
Received: from [192.168.48.131] ([10.86.241.0]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 14 Oct 2007 08:23:19 -0400
In-Reply-To: <6909c7$1m1bt8@sj-inbound-a.cisco.com>
References: <2166BDE3-E20D-4E45-B46D-CB8FB025C5FC@cisco.com>
	<14FE4A67-E8D3-4FE7-A686-CECA7BD519A4@cisco.com>
	<8AA97249241F7148BE6D3D8B93D83F5A0F5FB42B@ftrdmel2>
	<6909c7$1m1bt8@sj-inbound-a.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed
Message-Id: <A4A866EE-42F4-4919-85E0-5E4068D00F41@cisco.com>
Content-Transfer-Encoding: quoted-printable
From: JP Vasseur <jvasseur@cisco.com>
Subject: Re: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
Date: Sun, 14 Oct 2007 09:07:33 +0200
To: Lou Berger <lberger@labn.net>, gash5107@yahoo.com,
	Dimitri Papadimitriou <dpapadimitriou@psg.com>,
	Igor Bryskin <ibryskin@movaz.com>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 14 Oct 2007 12:23:20.0066 (UTC)
	FILETIME=[018A7E20:01C80E5D]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000
X-TM-AS-Result: No--15.587300-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10708; t=1192364620;
	x=1193228620; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jvasseur@cisco.com;
	z=From:=20JP=20Vasseur=20<jvasseur@cisco.com>
	|Subject:=20Re=3A=20[Pce]=20Update=20on=20draft-ietf-pce-policy-enabled-p
	ath-comp |Sender:=20
	|To:=20Lou=20Berger=20<lberger@labn.net>, =20gash5107@yahoo.com,
	=0A=20=20=
	20=20=20=20=20=20Dimitri=20Papadimitriou=20<dpapadimitriou@psg.com>,
	=0A=20
	=20=20=20=20=20=20=20Igor=20Bryskin=20<ibryskin@movaz.com>;
	bh=8bl5yQYtevNXH4v4dFlFc1ybNCuGh3kgrDOK8mmQN7c=;
	b=a7acrOxoDWNX651gCH8rtZ93i6rxWndv3cefNngCbuiouenUHfCFdfjGHeTX2CTQr1u5m1o8
	kqJ8eVI13Pl2i4ZvYDOltNGI3yNzlqp8U5qtuCC2xpxQGU7J3v+cdzcJ;
Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990
Cc: pce@ietf.org, Thomas Walsh <twalsh@juniper.net>,
	JACQUENET Christian RD-DDEV-REN <christian.jacquenet@orange-ftgroup.com>
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Hi Lou,

On Oct 12, 2007, at 11:25 PM, Lou Berger wrote:

> Christian,
>         Much thanks for the detailed comments.  We'll incorporate =20
> changes in the next rev.
>
> BTW one theme in your comments seems to come for the style of =20
> section 2 staying at a higher level (trying to focus on what can be =20=

> done) and the later sections getting into more of the details, =20
> e.g., PEP and PDP functions.  This approach was intentional and I'd =20=

> be surprised if the next rev radically departs from this.  That =20
> said, I think you have many good comments which will result in a =20
> more readable document once addressed.

Lou and co-authors, could you then try to address these comments, =20
post the new revision and
we will issue the WG LC right after.

Thanks.

JP.

>
> Thanks again for the input,
> Lou
>
>
> At 07:47 AM 10/9/2007, JACQUENET Christian RD-DDEV-REN wrote:
>
>> Dear all,
>>
>> Please find herein my comments, which are *not* on behalf of the =20
>> IPSF - only personal :-)
>>
>> 1. General:
>> I think this is a very useful document that clearly identifies the =20=

>> advantages of policy-based path computation management in PCE =20
>> environments. Nevertheless, I would encourage a refined =20
>> organization of the document, which would distinguish between the =20
>> framework (current sections 2.1, 4 and 5 basically), the =20
>> requirements (section 3, but also part of the text that relates to =20=

>> scenarios) and use cases or scenarios (sections 2.2.x, a bit of =20
>> sections 7 and 8).
>>
>> 2. Section 2.1, page 5:
>> The introductory sentence of the third paragraph implicly =20
>> indicates that PCE may very well behave as either a PDP (makes =20
>> decisions to be applied by PCC clients for example) or a PEP =20
>> (applies decisions possibly made by PCC clients and/or other PCE =20
>> components). I think this is one of the very key notions =20
>> introduced by this draft, and would therefore suggest an =20
>> introductory section that would elaborate on this heuristic, =20
>> possibly after the reminder about basic concepts of policy-based =20
>> management.
>>
>> 3. Section 2.1, page 6:
>> The last sentence of the first paragraph is slightly confusing: I =20
>> don't think the "or" is exclusive, that is, provider-defined =20
>> policies might very well be real time.
>>
>> 4. Section 2.2.3, page 11:
>> What's a policy-enabled PCC? A PCC that either embeds a PEP, a PDP =20=

>> or both? I think this should be elaborated, possibly in the =20
>> Terminology section. Note also that the last sentence of the page =20
>> mixes the notions of "making decision" and "apply user or service-=20
>> specific policies": since the text introduces a kind of causality =20
>> effect (the PEP embedded in the PCC enforces user or service-=20
>> specific policies, which seems to result in soliciting the PDP =20
>> embedded in the PEP to make decisions about the scope of =20
>> constraints that need to be taken into account for path =20
>> computation purposes), I would suggest a kind of flow diagram that =20=

>> could possibly elaborate on the corresponding chronology.
>>
>> 5. Section 2.2.3, page 12:
>> Related to the comment above, the sentence "when deciding=85" of the =20=

>> first paragraph may also suggest the activation of a LPDP =20
>> capability. I would also elaborate on the possible interactions =20
>> between the PEP, the PDP and the possible LPDP capabilities that =20
>> may be embedded in the PCC, assuming a differentiation "a la COPS =20
>> Client-Type". Who's the destinee of the path computation request =20
>> in the "once the constraints=85" sentence of the same paragraph - =20
>> the PCE? In the third paragraph, it seems that (1) The PCC embeds =20
>> a PDP that makes decisions about constraint-defined policies, (2) =20
>> Sends a path computation request that conveys the aforementioned =20
>> policy information towards the PCE, whose embedded PEP (3) Applies =20=

>> the corresponding decisions: is this statement correct? If so, I =20
>> don't understand why the PCE may "decide to reject the request": =20
>> that is, from a policy management standpoint, only the PEP of the =20
>> PCE is solicited in this context, which means that the PEP may not =20=

>> be capable of enforcing the decision, but I don't think the PEP is =20=

>> entitled to *reject* the decision, as part of a decision making =20
>> process. Maybe it's a wording issue. What would be the conditions =20
>> to send path computation requests to more than one PCE, aside from =20=

>> an inter-domain context? I'm not sure I understand why the =20
>> response sent by the PCE-PEP back to the requesting PCC-PDP may =20
>> indicate *policies*. Unless the document refers to a kind of PCE-=20
>> inferred feedback PIB (RFC 3571)? In that case, I would elaborate.
>>
>> 6. Section 3, page 15:
>> The notion of trusted nodes (as introdcued in the third paragraph) =20=

>> should deserve some elaboration, IMHO. The security considerations =20=

>> of this page should either be extended (e.g. preservation of the =20
>> confidentiality of the information that will be exchanged between =20
>> a PDP and a set of PDPs), or reference the "true" Security =20
>> Considerations section of the document, which BTW, rightfully =20
>> elaborates on such issues.
>>
>> 7. Section 5, page 18:
>> I don't understand why a protocol like COPS couldn't be used in =20
>> the case where PEP and PDP are colocated. In any case, a protocol =20
>> is required to convey the exchanges between the PEP and the PDP=85 =20=

>> In addition (last line of the page), it's very unlikely that SNMP =20
>> will be used to retrieve information from a PIB.
>>
>> 8. Section 5, page 19:
>> I would suggest some elaboration on the kind of information any =20
>> given PEP (PCC or PCE) may receive from another *PEP* - is this a =20
>> typo (i.e. read PDP instead), or does this relate to information =20
>> different from "policy-related" information or else? In a COPS =20
>> context, multiple Client-Types can certainly reside and coexist =20
>> within a PEP, but I'm not sure I understand why PEPs would =20
>> exchange information. Also, the following paragraph ("any given =20
>> policy=85") is a bit confusing to me: I don't understand this notion =20=

>> of partial interpretation, and would rather suggest another =20
>> wording - enforcement instead of interpretation. Besides, I'm not =20
>> sure this paragraph helps in understanding the roles played by =20
>> PEPs and PDPs.
>>
>> 9. Section 6.1., page 20:
>> Why *all* PC policy types used in the net *must* be applied? It's =20
>> a "Client-Type" specific thing, IMHO.
>>
>> 10. Section 6.1., page 21:
>> In the first paragraph, I don't understand why the PCE selection =20
>> should be static. Even if the policy enforcement is restricted to =20
>> the PCE (for path computation purposes), nothing prevents a PEP =20
>> embedded in a PCC to support the relevant "Client-Type", hence =20
>> yielding the dynamic identification of the corresponding PCE, by =20
>> means of the COPS-like OPEN message at PCC bootstrap, for example. =20=

>> In the third paragraph, the "must" of the first sentence is too =20
>> strong, IMHO, unless the sentence means that any kind of policy =20
>> must "encouarge" the support of the corresponding "Client-Types" =20
>> in the PCC-PEP. If so, I would rephrase.
>>
>> 11. Section 6.2., page 22:
>> I don't understand why matching repositories would result in a =20
>> single PC repository, unless further elaboration on such match is =20
>> provided.
>>
>> 12. Section 6.3, page 23:
>> Does the figure relate to PCE instead of PCC (same for figure 12)?
>>
>> 13. Section 7.1., page 25:
>> What's an "objection function"?
>>
>> 14. Typos:
>> TED =3D Traffic Engineering Database? SRLG =3D Shared Risk Link =
Group? =20
>> Page 16, provide the normative reference associated to LDAPv3. =20
>> Page 17, remove the "s" of the very last word of the page.
>>
>> Cheers,
>>
>> Christian.
>>
>>
>> ----------
>> De : JP Vasseur [mailto:jvasseur@cisco.com]
>> Envoy=E9 : lundi 8 octobre 2007 22:36
>> =C0 : pce@ietf.org; Lou Berger; Igor Bryskin; Dimitri Papadimitriou; =20=

>> gash5107@yahoo.com
>> Cc : Thomas Walsh; JACQUENET Christian RD-DDEV-REN
>> Objet : Fwd: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
>>
>> Dear WG,
>>
>> Christian Jacquenet on behalf of IPSphere proposed to make several =20=

>> comments on this document.
>> Christian, could you please send them to the list ?
>>
>> As agreed, we're still planning to issue a WG LC after this round =20
>> of discussion.
>>
>> Thanks.
>>
>> JP.
>>
>> Begin forwarded message:
>>
>>> From: JP Vasseur <<mailto:jvasseur@cisco.com>jvasseur@cisco.com>
>>> Date: September 18, 2007 2:10:12 PM EDT
>>> To: <mailto:pce@ietf.org>pce@ietf.org, Lou Berger =20
>>> <<mailto:lberger@labn.net>lberger@labn.net>, Igor Bryskin =20
>>> <<mailto:ibryskin@movaz.com>ibryskin@movaz.com>,  Dimitri =20
>>> Papadimitriou =20
>>> <<mailto:dpapadimitriou@psg.com>dpapadimitriou@psg.com>, =20
>>> <mailto:gash5107@yahoo.com>gash5107@yahoo.com
>>> Cc: Thomas Walsh =20
>>> <<mailto:twalsh@juniper.net>twalsh@juniper.net>,  JACQUENET =20
>>> Christian RD-TCH-REN =20
>>> <<mailto:christian.jacquenet@francetelecom.com>christian.jacquenet@f=20=

>>> rancetelecom.com>
>>> Subject: [Pce] Update on draft-ietf-pce-policy-enabled-path-comp
>>>
>>> Dear WG,
>>>
>>> =46rom the WG minutes of the IETF-69 meeting:
>>>
>>> 12) Update on Policy-Enabled Path Computation Framework
>>> draft-ietf-pce-policy-enabled-path-comp-01.txt (Lou - 5mn) [110]
>>>
>>> Lou> ready for Last Call
>>> JP> It sounds ready. Suggestion: offer IPSphere to have a look at =20=

>>> the doc before last call. JP will be the point
>>> of contact. Asked Ross whether this is a good idea, and Ross =20
>>> agreed. Once comments are received, last call.
>>> Adrian> OK, but this is not an indefinite consultation. We want =20
>>> to be able to move ahead and complete the I-D
>>> relatively soon.
>>>
>>> We have contacted IPSphere and RA WG of IPSphere should provide =20
>>> us some feed-back by
>>> mid-October. I have copied Tom Walsh and Christian Jacquenet =20
>>> (chair of the RAWG) IPSphere.
>>>
>>> Thanks.
>>>
>>> JP.
>>> _______________________________________________
>>> Pce mailing list
>>> <mailto:Pce@lists.ietf.org>Pce@lists.ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pce


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Tue Oct 16 11:22:02 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IhoEt-0004Ht-Ux; Tue, 16 Oct 2007 11:21:48 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IhoEp-00045Q-UX
	for pce-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 11:21:43 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IhoEn-00041a-UI; Tue, 16 Oct 2007 11:21:42 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IhoEn-0007O6-Cy; Tue, 16 Oct 2007 11:21:41 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DA92E175AC;
	Tue, 16 Oct 2007 15:21:40 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IhoEm-0007BK-Dw; Tue, 16 Oct 2007 11:21:40 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1IhoEm-0007BK-Dw@stiedprstage1.ietf.org>
Date: Tue, 16 Oct 2007 11:21:40 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: Internet Architecture Board <iab@iab.org>, pce mailing list <pce@ietf.org>,
	pce chair <pce-chairs@tools.ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Pce] Protocol Action: 'OSPF Protocol Extensions for Path 
 Computation Element (PCE) Discovery' to Proposed Standard 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

The IESG has approved the following document:

- 'OSPF Protocol Extensions for Path Computation Element (PCE) 
   Discovery '
   <draft-ietf-pce-disco-proto-ospf-08.txt> as a Proposed Standard

This document is the product of the Path Computation Element Working 
Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-ospf-08.txt

Technical Summary
 
   There are various circumstances where it is highly desirable for a
   Path Computation Client (PCC) to be able to dynamically and
   automatically discover a set of Path Computation Elements (PCE),
   along with some information that can be used for PCE selection. When
   the PCE is a Label Switching Router (LSR) participating in the
   Interior Gateway Protocol (IGP), or even a server participating
   passively in the IGP, a simple and efficient way to discover PCEs
   consists of using IGP flooding. For that purpose, this document
   defines extensions to the Open Shortest Path First (OSPF) routing
   protocol for the advertisement of PCE Discovery information within an
   OSPF area or within the entire OSPF routing domain.
 
Working Group Summary
 
   No dissent reported. The choice is relatively obvious for networks 
   running OSPF. Of course an IS-IS version is also needed for those
   networks that are running IS-IS (and will be submitted to the IESG
   soon). 
 
Protocol Quality
 
   Ross Callon has reviewed this spec for the IESG. I will check on 
   whether there are implementations. 

Note to RFC Editor
 
   Section 1:  Insert two new terms in alphabetic order in the list 
   as follows:

     PCED: PCE Discovery.

     TLV: Type-Length-Variable data encoding.

   Section 4.1

   OLD
     The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
     PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and 
     IPv6 address. It MUST NOT appear more than once for the same
     address type. If it appears more than once, only the first
     occurrence is processed and any others MUST be ignored.

   NEW
     The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
     PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and 
     IPv6 address. It MUST NOT appear more than once for the same 
     address type. If it appears more than once for the same address 
     type, only the first occurrence is processed and any others MUST be
     ignored.

   Section 5, in the fourth paragraph, remove the last two sentences. 
   Thus:

   OLD
     The PCE address (i.e., the address indicated within the PCE ADDRESS 
     sub-TLV) SHOULD be reachable via some prefixes advertised by OSPF. 
     This allows the detection of a PCE failure to be sped up. When the 
     PCE address is no longer reachable, the PCE node has failed, has 
     been torn down, or there is no longer IP connectivity to the PCE 
     node.

   NEW
     The PCE address (i.e., the address indicated within the PCE ADDRESS 
     sub-TLV) SHOULD be reachable via some prefixes advertised by OSPF. 

   Insert immediately after this paragraph: 

     The PCED TLV information regarding a specific PCE is
     only considered current and useable when the router
     advertising this information is itself reachable via 
     OSPF calculated paths in the same area of the LSA in which
     the PCED TLV appears.

     A change in the state of a PCE (activate, deactivate, 
     parameter change) MUST result in a corresponding change in
     the PCED TLV information advertised by an OSPF router
     (inserted, removed, updated) in its LSA. The way PCEs
     determine the information they advertise and how that
     information is made available to OSPF is out of the scope
     of this document. Some information may be configured (e.g.,
     address, preferences, scope) and other information may be
     automatically determined by the PCE (e.g. areas of visibility).

   Delete the last paragraph of section 5 (this paragraph begins "The 
   way PCEs determine...", and has been moved up in the text). 

   Replace all of section 9.3 with the following text:

     9.3. Liveness Detection and Monitoring

     This document specifies the use of OSPF as a PCE Discovery 
     Protocol. The requirements specified in RFC 4674 include the 
     ability to determine liveness of the PCE Discovery protocol.
     Normal operation of the OSPF protocol meets these requirements. 

   Section 10

   OLD
     We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, and
     Tim Polk for their comments during the final stages of publication.

   NEW
     We would also like to thank Dave Ward, Lars Eggert, Sam Hartman, Tim
     Polk, and Lisa Dusseault for their comments during the final stages 
     of publication.



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Tue Oct 16 11:24:42 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IhoHQ-0000Of-Ix; Tue, 16 Oct 2007 11:24:24 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IhoHO-0000LN-KU
	for pce-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 11:24:22 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IhoHN-0000K4-Q2; Tue, 16 Oct 2007 11:24:21 -0400
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IhoHN-0007T0-7q; Tue, 16 Oct 2007 11:24:21 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C9587175AC;
	Tue, 16 Oct 2007 15:24:15 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IhoHH-0007Dd-Bg; Tue, 16 Oct 2007 11:24:15 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1IhoHH-0007Dd-Bg@stiedprstage1.ietf.org>
Date: Tue, 16 Oct 2007 11:24:15 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Cc: Internet Architecture Board <iab@iab.org>, pce mailing list <pce@ietf.org>,
	pce chair <pce-chairs@tools.ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Pce] Protocol Action: 'IS-IS Protocol Extensions for Path 
 Computation Element (PCE) Discovery' to Proposed Standard 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

The IESG has approved the following document:

- 'IS-IS Protocol Extensions for Path Computation Element (PCE) 
   Discovery '
   <draft-ietf-pce-disco-proto-isis-08.txt> as a Proposed Standard

This document is the product of the Path Computation Element Working 
Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-isis-08.txt

Technical Summary
 
   There are various circumstances where it is highly desirable for a 
   Path Computation Client (PCC) to be able to dynamically and 
   automatically discover a set of Path Computation Elements (PCEs), 
   along with information that can be used by the PCC for PCE selection. 
   When the PCE is a Label Switching Router (LSR) participating in the 
   Interior Gateway Protocol (IGP), or even a server participating 
   passively in the IGP, a simple and efficient way to announce PCEs 
   consists of using IGP flooding. For that purpose this document 
   defines extensions to the Intermediate System to Intermediate System 
   (IS-IS) routing protocol for the advertisement of PCE Discovery 
   information within an IS-IS area or within the entire IS-IS routing 
   domain.
 
Working Group Summary
 
   No dissent reported (see PROTO writeup by Adrian Farrel). 
 
Protocol Quality
 
   Ross Callon has reviewed the spec for the IESG. Two downref's were
   called out during the second IETF last call, and have been added to 
   the downref directory. Also, note that this document is very similar
   to the equivalent OSPF document, draft-ietf-pce-disco-proto-ospf. 
   The changes that came up during IESG review of the OSPF document 
   have also been made to this document. 

Note to RFC Editor
 
   The reference to [IS-IS-CAP] will need to be replaced by a reference
   to RFC 4971. 

   Near the bottom of page 4, eigth paragraph of section 2 the double 
   paretheses should be removed. Thus "([IS-IS-CAP])" is replaced with
   "[IS-IS-CAP]", or more precisely with "[RFC 4971]".

   Section 4.1

   OLD
     The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
     PCED sub-TLV. It MAY appear twice, when the PCE has both an IPv4 and
     IPv6 address. It MUST NOT appear more than once for the same address
     type. If it appears more than once only the first occurrence is
     processed and any others MUST be ignored.

   NEW
     The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
     PCED sub-TLV. It MAY appear twice, when the PCE has both an IPv4 and
     IPv6 address. It MUST NOT appear more than once for the same address
     type. If it appears more than once for the same address type, only
     the first occurrence is processed and any others MUST be ignored.

   Section 5, in the fifth paragraph, remove the last two sentences.
   Thus:

   OLD
     The PCE address (i.e., the address indicated within the PCE ADDRESS 
     sub-TLV) SHOULD be reachable via some prefixes advertised by IS-IS. 
     This allows the detection of a PCE failure to be sped up. When the 
     PCE address is no longer reachable, the PCE node has failed, has 
     been torn down, or there is no longer IP connectivity to the PCE 
     node.

   NEW
     The PCE address (i.e., the address indicated within the PCE ADDRESS 
     sub-TLV) SHOULD be reachable via some prefixes advertised by IS-IS. 

   Insert immediately after this paragraph: 

     The PCED sub-TLV information regarding a specific PCE is
     only considered current and useable when the router
     advertising this information is itself reachable via 
     IS-IS calculated paths at the level of the LSP in which
     the PCED sub-TLV appears.

     A change in the state of a PCE (activate, deactivate, 
     parameter change) MUST result in a corresponding change in
     the PCED sub-TLV information advertised by an IS-IS router
     (inserted, removed, updated) in its LSP. The way PCEs
     determine the information they advertise and how that
     information is made available to IS-IS is out of the scope
     of this document. Some information may be configured (e.g.,
     address, preferences, scope) and other information may be
     automatically determined by the PCE (e.g. areas of visibility).

   Delete the last paragraph of section 5 (this paragraph begins 
   "The way PCEs determine...", and has been moved up in the text). 

   Replace all of section 9.3 with the following text:

     9.3. Liveness Detection and Monitoring

     This document specifies the use of IS-IS as a PCE Discovery
     Protocol. The requirements specified in RFC 4674 include the 
     ability to determine liveness of the PCE Discovery protocol.
     Normal operation of the IS-IS protocol meets these requirements.

   Section 10

   OLD
     We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike
     Shand, Lou Berger, and David Ward, for their useful comments and
     suggestions.

   NEW
     We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike
     Shand, Lou Berger, David Ward, Ross Callon, and Lisa Dusseault for 
     their useful comments and suggestions.



_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Sat Oct 20 13:09:56 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IjHne-0002k1-5z; Sat, 20 Oct 2007 13:07:46 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IjHnd-0002jM-JV
	for pce-confirm+ok@megatron.ietf.org; Sat, 20 Oct 2007 13:07:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IjHnc-0002i8-M3
	for pce@ietf.org; Sat, 20 Oct 2007 13:07:44 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjHnW-00016G-BN
	for pce@ietf.org; Sat, 20 Oct 2007 13:07:44 -0400
X-IronPort-AV: E=Sophos;i="4.21,304,1188792000"; 
	d="scan'208,217";a="135282559"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2007 13:07:23 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9KH7Noh021984
	for <pce@ietf.org>; Sat, 20 Oct 2007 13:07:23 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9KH7Nk7026740
	for <pce@ietf.org>; Sat, 20 Oct 2007 17:07:23 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 20 Oct 2007 13:07:22 -0400
Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 20 Oct 2007 13:07:21 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
To: pce@ietf.org
Message-Id: <80099E7F-06B5-41F2-AD1C-0980203E31A6@cisco.com>
References: <E1Iij1l-0002E3-Ua@stiedprstage1.ietf.org>
From: JP Vasseur <jvasseur@cisco.com>
Date: Sat, 20 Oct 2007 13:06:19 -0400
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 20 Oct 2007 17:07:22.0129 (UTC)
	FILETIME=[ADE17010:01C8133B]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15494.000
X-TM-AS-Result: No--33.688400-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14091; t=1192900043;
	x=1193764043; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jvasseur@cisco.com;
	z=From:=20JP=20Vasseur=20<jvasseur@cisco.com>
	|Subject:=20Fwd=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for=
	20the=2070th=20IETF=20=20Meeting=20in=20Vancouver,=20BC,=20Canada=20
	|Sender:=20 |To:=20pce@ietf.org;
	bh=16KaizDJ791kGniwMpFp0ZGZXC2K9mSqFH6BlB/VgSM=;
	b=nbhb0NYxmwO8xxrZMk282MYDcRiTkMntd61tuO4nOrCOZYScA4K8iuLYPthCIsM+A5/dgqxU
	SNtUNuZ/7rMpOHHJ/8iL8wuf676bX8Y/3ECAhDgPfxgKoq32iFrB6TI6;
Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.6 (/)
X-Scan-Signature: c2e58d9873012c90703822e287241385
Cc: 
Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the 70th
	IETF Meeting in Vancouver, BC, Canada 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1483093784=="
Errors-To: pce-bounces@lists.ietf.org




--===============1483093784==
Content-Type: multipart/alternative; boundary=Apple-Mail-99--155584897




--Apple-Mail-99--155584897
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed



Begin forwarded message:

> From: ietf-secretariat@ietf.org
> Date: October 19, 2007 12:00:01 AM EDT
> To: ietf-announce@ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 70th IETF   
> Meeting in Vancouver, BC, Canada
>
> There are two (2) Internet-Draft cutoff dates for the 70th
> IETF Meeting in Vancouver, BC, Canada:
>
> November 12th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> November 12th at 9:00 AM ET (14:00 UTC/GMT). As always, all initial  
> submissions with a
> filename beginning with "draft-ietf" must be approved by the
> appropriate WG Chair before they can be processed or announced.  The
> Secretariat would appreciate receiving WG Chair approval by Monday,
> November 5th at 9:00 AM ET (14:00 UTC/GMT).
>
> November  (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version  
> -01 and higher)
> Internet-Draft Submissions
>
> All revised Internet-Drafts (version -01 and higher) must be submitted
> by Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT).
>
> Initial and revised Internet-Drafts received after their respective
> cutoff dates will not be made available in the Internet-Drafts
> directory or announced until on or after Monday, December 3rd at 9:00
> AM ET (14:00 UTC/GMT), when Internet-Draft posting resumes.  Please  
> do not wait until
> the last minute to submit.
>
> The Secretariat encourages you to submit your Internet-Drafts via  
> the Internet-Draft
> Submission Tool (IDST) https://datatracker.ietf.org/idst/ 
> upload.cgi. If you are unable to do
> so, then you may still submit your Internet-Drafts manually by  
> sending them to internet-
> drafts@ietf.org.  If you are submitting a version -00 WG draft that  
> replaces non-WG draft,
> then you must submit it manually as the current IDST cannot handle  
> replacements.  Please be
> sure to state that one draft replaces another in the cover note  
> that accompanies your
> submission.  Also, please note that the IDST will not accept drafts  
> submitted after their
> respective cutoff dates.
>
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> internet-drafts@ietf.org.
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant  
> dates
> for the 70th IETF Meeting can be found at http://www.ietf.org/ 
> meetings/cutoff_dates_70.html.
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce


--Apple-Mail-99--155584897
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">
<br><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px =
Helvetica"><a =
href=3D"mailto:ietf-secretariat@ietf.org">ietf-secretariat@ietf.org</a></f=
ont></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>Date: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica">October 19, 2007 12:00:01 AM =
EDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica"><a =
href=3D"mailto:ietf-announce@ietf.org">ietf-announce@ietf.org</a></font></=
div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" =
color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica"><b>Internet-Drafts Submission Cutoff =
Dates for the 70th IETF<span class=3D"Apple-converted-space">=A0 =
</span>Meeting in Vancouver, BC, Canada<span =
class=3D"Apple-converted-space">=A0</span></b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div> <div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">There =
are two (2) Internet-Draft cutoff dates for the 70th<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">IETF =
Meeting in Vancouver, BC, Canada:</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">November 12th: Cutoff Date for =
Initial (i.e., version -00)<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Internet-Draft Submissions<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">All initial =
Internet-Drafts (version -00) must be submitted by Monday,<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">November =
12th at 9:00 AM ET (14:00 UTC/GMT). As always, all initial submissions =
with a<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">filename beginning with "draft-ietf" must be =
approved by the<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">appropriate WG Chair before they can be processed or =
announced.<span class=3D"Apple-converted-space">=A0 </span>The<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Secretariat would appreciate receiving WG Chair approval by =
Monday,<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">November 5th at 9:00 AM ET (14:00 =
UTC/GMT).</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">November<span class=3D"Apple-converted-space">=A0 =
</span>(14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and =
higher)<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Internet-Draft Submissions<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">All revised =
Internet-Drafts (version -01 and higher) must be submitted<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">by =
Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT).</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Initial =
and revised Internet-Drafts received after their respective<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">cutoff =
dates will not be made available in the Internet-Drafts<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">directory or announced until on or after Monday, December 3rd at =
9:00<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">AM ET (14:00 UTC/GMT), when Internet-Draft posting =
resumes.<span class=3D"Apple-converted-space">=A0 </span>Please do not =
wait until<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">the last minute to submit.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
Secretariat encourages you to submit your Internet-Drafts via the =
Internet-Draft<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Submission Tool (IDST) <a =
href=3D"https://datatracker.ietf.org/idst/upload.cgi">https://datatracker.=
ietf.org/idst/upload.cgi</a>. If you are unable to do<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">so, then =
you may still submit your Internet-Drafts manually by sending them to =
internet-</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"mailto:drafts@ietf.org">drafts@ietf.org</a>.<span =
class=3D"Apple-converted-space">=A0 </span>If you are submitting a =
version -00 WG draft that replaces non-WG draft,<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">then you =
must submit it manually as the current IDST cannot handle =
replacements.<span class=3D"Apple-converted-space">=A0 </span>Please =
be<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">sure to state that one draft replaces another in the =
cover note that accompanies your<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">submission.<span class=3D"Apple-converted-space">=A0 </span>Also, =
please note that the IDST will not accept drafts submitted after =
their<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">respective cutoff dates.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Thank =
you for your understanding and cooperation. If you have any<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">questions or concerns, then please send a message to<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>.</di=
v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The IETF =
Secretariat</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">FYI: The Internet-Draft cutoff dates as well as =
other significant dates</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">for the 70th =
IETF Meeting can be found at <a =
href=3D"http://www.ietf.org/meetings/cutoff_dates_70.html">http://www.ietf=
.org/meetings/cutoff_dates_70.html</a>.</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"mailto:IETF-Announce@ietf.org">IETF-Announce@ietf.org</a></div><di=
v style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</a></div> =
</blockquote></div><br></body></html>=

--Apple-Mail-99--155584897--



--===============1483093784==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============1483093784==--





From pce-bounces@lists.ietf.org Tue Oct 23 08:51:26 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IkJDU-0004Iz-CZ; Tue, 23 Oct 2007 08:50:40 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IkJDN-00048c-UW
	for pce-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 08:50:33 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IkJDN-000484-4l; Tue, 23 Oct 2007 08:50:33 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IkJDM-0004pm-Oj; Tue, 23 Oct 2007 08:50:33 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A42C32AC8A;
	Tue, 23 Oct 2007 12:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IkJCr-0005S6-LD; Tue, 23 Oct 2007 08:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1IkJCr-0005S6-LD@stiedprstage1.ietf.org>
Date: Tue, 23 Oct 2007 08:50:01 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: pce@ietf.org
Subject: [Pce] I-D Action:draft-ietf-pce-dste-00.txt 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

--NextPart

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           : Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol
	Author(s)       : S. Sivabalan, et al.
	Filename        : draft-ietf-pce-dste-00.txt
	Pages           : 1
	Date            : 2007-10-23

This document specifies a CLASSTYPE object to support Diff-Serve 

  Aware Traffic Engineering (DS-TE) where path computation is 

  performed with an aid of Path Computation Element (PCE). 

  Conventions used in this document 


  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 

  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 

  "OPTIONAL" in this document are to be interpreted as described 

  in RFC-2119.

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

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@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-dste-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@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pce-dste-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-10-23084357.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pce-dste-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-pce-dste-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-10-23084357.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--NextPart--





From pce-bounces@lists.ietf.org Wed Oct 24 08:27:50 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IkfKb-0004Gd-05; Wed, 24 Oct 2007 08:27:29 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IkJ7J-0003Jn-Jp
	for pce-confirm+ok@megatron.ietf.org; Tue, 23 Oct 2007 08:44:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJ7I-0003Ib-6K
	for pce@ietf.org; Tue, 23 Oct 2007 08:44:16 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkJ7G-0005oU-T5
	for pce@ietf.org; Tue, 23 Oct 2007 08:44:16 -0400
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns1.neustar.com (Postfix) with ESMTP id A93DD26E6E;
	Tue, 23 Oct 2007 12:44:00 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IkJ72-0005dF-JQ; Tue, 23 Oct 2007 08:44:00 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: jdparker@cisco.com
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Message-Id: <E1IkJ72-0005dF-JQ@ietf.org>
Date: Tue, 23 Oct 2007 08:44:00 -0400
X-Spam-Score: -1.4 (-)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
X-Mailman-Approved-At: Wed, 24 Oct 2007 08:27:28 -0400
Cc: pce@ietf.org, msiva@cisco.com, sboutros@cisco.com
Subject: [Pce] New Version Notification for draft-ietf-pce-dste-00 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org


A new version of I-D, draft-ietf-pce-dste-00.txt has been successfuly submitted by Jon Parker and posted to the IETF repository.

Filename:	 draft-ietf-pce-dste
Revision:	 00
Title:		 Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol
Creation_date:	 2007-10-23
WG ID:		 pce
Number_of_pages: 1

Abstract:
This document specifies a CLASSTYPE object to support Diff-Serve 

  Aware Traffic Engineering (DS-TE) where path computation is 

  performed with an aid of Path Computation Element (PCE). 

  Conventions used in this document 


  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 

  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 

  "OPTIONAL" in this document are to be interpreted as described 

  in RFC-2119.
                                                                                  


The IETF Secretariat.




_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Fri Oct 26 10:07:38 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IlPq1-0003HT-Qb; Fri, 26 Oct 2007 10:07:01 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1IlPq0-0003H0-3G
	for pce-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 10:07:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IlPpy-0003GJ-Gt
	for pce@ietf.org; Fri, 26 Oct 2007 10:06:59 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlPps-00064P-Rc
	for pce@ietf.org; Fri, 26 Oct 2007 10:06:58 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-4.cisco.com with ESMTP; 26 Oct 2007 07:06:39 -0700
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9QE6ctn021502
	for <pce@ietf.org>; Fri, 26 Oct 2007 10:06:38 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9QE6cBE003503
	for <pce@ietf.org>; Fri, 26 Oct 2007 14:06:38 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 26 Oct 2007 10:06:38 -0400
Received: from [161.44.71.191] ([161.44.71.191]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 26 Oct 2007 10:06:37 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
To: pce@ietf.org
Message-Id: <271B7866-45A4-4FD3-9A30-BA8AB2B11229@cisco.com>
References: <E1IlGMc-0001Vw-76@stiedprstage1.ietf.org>
From: JP Vasseur <jvasseur@cisco.com>
Date: Fri, 26 Oct 2007 10:05:33 -0400
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 26 Oct 2007 14:06:37.0917 (UTC)
	FILETIME=[6CB480D0:01C817D9]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002
X-TM-AS-Result: No--33.688400-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14501; t=1193407598;
	x=1194271598; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jvasseur@cisco.com;
	z=From:=20JP=20Vasseur=20<jvasseur@cisco.com>
	|Subject:=20Fwd=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for=
	20the=2070th=20IETF=20=20Meeting=20in=20Vancouver,=20BC,=20Canada=20
	|Sender:=20 |To:=20pce@ietf.org;
	bh=HAS7jNWMDbYR+7ODVbDu+CNY5TMU14Mx/zT/IBGRMnY=;
	b=BUbkoll2aU98N8p5MXkTNTmNx74/Muvx1pknINmebz70HD5lAVpd94vmXzOOYfq26YQFCcN6
	FPbh7Ra11gdAgfxgUnBjG7YPVKOZ8y++QAekkMk7raMZ0M0E1XPcPWfD;
Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: -3.4 (---)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Cc: 
Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the 70th
	IETF Meeting in Vancouver, BC, Canada 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0465160961=="
Errors-To: pce-bounces@lists.ietf.org




--===============0465160961==
Content-Type: multipart/alternative; boundary=Apple-Mail-162-351968960




--Apple-Mail-162-351968960
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed



Begin forwarded message:

> From: ietf-secretariat@ietf.org
> Date: October 26, 2007 12:00:02 AM EDT
> To: ietf-announce@ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 70th IETF   
> Meeting in Vancouver, BC, Canada
>
>
> There are two (2) Internet-Draft cutoff dates for the 70th
> IETF Meeting in Vancouver, BC, Canada:
>
> November 12th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> November 12th at 9:00 AM ET (14:00 UTC/GMT). As always, all initial  
> submissions with a
> filename beginning with "draft-ietf" must be approved by the
> appropriate WG Chair before they can be processed or announced.  The
> Secretariat would appreciate receiving WG Chair approval by Monday,
> November 5th at 9:00 AM ET (14:00 UTC/GMT).
>
> November  (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version  
> -01 and higher)
> Internet-Draft Submissions
>
> All revised Internet-Drafts (version -01 and higher) must be submitted
> by Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT).
>
> Initial and revised Internet-Drafts received after their respective
> cutoff dates will not be made available in the Internet-Drafts
> directory or announced until on or after Monday, December 3rd at 9:00
> AM ET (14:00 UTC/GMT), when Internet-Draft posting resumes.  Please  
> do not wait until
> the last minute to submit.
>
> The Secretariat encourages you to submit your Internet-Drafts via the
> Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/ 
> idst/upload.cgi.
> If you are unable to do so, then you may still submit your Internet-
> Drafts manually by sending them to internet-drafts@ietf.org.  If you
> are submitting a version -00 WG draft that replaces non-WG draft, then
> you must submit it manually as the current IDST cannot handle
> replacements.  Please be sure to state that one draft replaces another
> in the cover note that accompanies your submission.  Also, please note
> that the IDST will not accept drafts submitted after their respective
> cutoff dates.
>
> Thank you for your understanding and cooperation. If you have any
> questions or concerns, then please send a message to
> internet-drafts@ietf.org.
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant  
> dates
> for the 70th IETF Meeting can be found at http://www.ietf.org/ 
> meetings/cutoff_dates_70.html.
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce


--Apple-Mail-162-351968960
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">
<br><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 16.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 16.0px =
Helvetica"><a =
href=3D"mailto:ietf-secretariat@ietf.org">ietf-secretariat@ietf.org</a></f=
ont></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>Date: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica">October 26, 2007 12:00:02 AM =
EDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica"><a =
href=3D"mailto:ietf-announce@ietf.org">ietf-announce@ietf.org</a></font></=
div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" =
color=3D"#000000" style=3D"font: 16.0px Helvetica; color: =
#000000"><b>Subject: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 16.0px Helvetica"><b>Internet-Drafts Submission Cutoff =
Dates for the 70th IETF<span class=3D"Apple-converted-space">=A0 =
</span>Meeting in Vancouver, BC, Canada<span =
class=3D"Apple-converted-space">=A0</span></b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div> <div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">There are two =
(2) Internet-Draft cutoff dates for the 70th<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">IETF =
Meeting in Vancouver, BC, Canada:</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">November 12th: Cutoff Date for =
Initial (i.e., version -00)<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Internet-Draft Submissions<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">All initial =
Internet-Drafts (version -00) must be submitted by Monday,<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">November =
12th at 9:00 AM ET (14:00 UTC/GMT). As always, all initial submissions =
with a<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">filename beginning with "draft-ietf" must be =
approved by the<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">appropriate WG Chair before they can be processed or =
announced.<span class=3D"Apple-converted-space">=A0 </span>The<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Secretariat would appreciate receiving WG Chair approval by =
Monday,<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">November 5th at 9:00 AM ET (14:00 =
UTC/GMT).</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">November<span class=3D"Apple-converted-space">=A0 =
</span>(14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and =
higher)<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Internet-Draft Submissions<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">All revised =
Internet-Drafts (version -01 and higher) must be submitted<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">by =
Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT).</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Initial =
and revised Internet-Drafts received after their respective<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">cutoff =
dates will not be made available in the Internet-Drafts<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">directory or announced until on or after Monday, December 3rd at =
9:00<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">AM ET (14:00 UTC/GMT), when Internet-Draft posting =
resumes.<span class=3D"Apple-converted-space">=A0 </span>Please do not =
wait until<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">the last minute to submit.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The =
Secretariat encourages you to submit your Internet-Drafts via the<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Internet-Draft Submission Tool (IDST) <a =
href=3D"https://datatracker.ietf.org/idst/upload.cgi">https://datatracker.=
ietf.org/idst/upload.cgi</a>.<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">If you =
are unable to do so, then you may still submit your Internet-</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Drafts manually by sending them to <a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>.<spa=
n class=3D"Apple-converted-space">=A0 </span>If you<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">are =
submitting a version -00 WG draft that replaces non-WG draft, then<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">you must =
submit it manually as the current IDST cannot handle<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">replacements.<span class=3D"Apple-converted-space">=A0 </span>Please =
be sure to state that one draft replaces another<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in the =
cover note that accompanies your submission.<span =
class=3D"Apple-converted-space">=A0 </span>Also, please note<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">that the =
IDST will not accept drafts submitted after their respective<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">cutoff =
dates.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Thank you for your understanding and cooperation. If =
you have any<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">questions or concerns, then please send a message =
to<span class=3D"Apple-converted-space">=A0</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>.</di=
v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The IETF =
Secretariat</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">FYI: The Internet-Draft cutoff dates as well as =
other significant dates</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">for the 70th =
IETF Meeting can be found at <a =
href=3D"http://www.ietf.org/meetings/cutoff_dates_70.html">http://www.ietf=
.org/meetings/cutoff_dates_70.html</a>.</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IETF-Announce mailing list</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"mailto:IETF-Announce@ietf.org">IETF-Announce@ietf.org</a></div><di=
v style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"https://www1.ietf.org/mailman/listinfo/ietf-announce">https://www1=
.ietf.org/mailman/listinfo/ietf-announce</a></div> =
</blockquote></div><br></body></html>=

--Apple-Mail-162-351968960--



--===============0465160961==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============0465160961==--





From pce-bounces@lists.ietf.org Tue Oct 30 14:08:44 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1ImvVR-0002y4-Im; Tue, 30 Oct 2007 14:08:01 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1ImvVR-0002xz-8N
	for pce-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:08:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1ImvVQ-0002xr-Ux
	for pce@ietf.org; Tue, 30 Oct 2007 14:08:00 -0400
Received: from tama55.ecl.ntt.co.jp ([129.60.39.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImvVP-0006AT-DF
	for pce@ietf.org; Tue, 30 Oct 2007 14:08:00 -0400
Received: from sfs2.omr.ecl.ntt.co.jp (IDENT:mirapoint@sfs2.omr.ecl.ntt.co.jp
	[129.60.39.117])
	by tama55.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l9UI7Y08005388
	for <pce@ietf.org>; Wed, 31 Oct 2007 03:07:43 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
	by sfs2.omr.ecl.ntt.co.jp (MOS 3.8.4-GA) with ESMTP id BHU33177;
	Wed, 31 Oct 2007 03:04:42 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
	by mfs3.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8611751F9B2
	for <pce@ietf.org>; Wed, 31 Oct 2007 03:04:42 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
	by mfs3.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 544ED51F9A5
	for <pce@ietf.org>; Wed, 31 Oct 2007 03:04:42 +0900 (JST)
Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp
	[129.60.5.68])
	by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l9UI4e1F013970
	for <pce@ietf.org>; Wed, 31 Oct 2007 03:04:40 +0900 (JST)
Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	l9UI4dlh026464
	for <pce@ietf.org>; Wed, 31 Oct 2007 03:04:39 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140])
	by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id
	l9UI4ddb026459
	for <pce@ietf.org>; Wed, 31 Oct 2007 03:04:39 +0900 (JST)
Received: from [129.60.80.54] ([129.60.80.54])
	by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l9UI4aW8006928
	for <pce@ietf.org>; Wed, 31 Oct 2007 03:04:39 +0900 (JST)
Date: Wed, 31 Oct 2007 03:03:52 +0900
From: Eiji Oki <oki.eiji@lab.ntt.co.jp>
To: pce@ietf.org
Message-Id: <20071031030322.210E.OKI.EIJI@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------_4726F224E9C209E19F18_MULTIPART_MIXED_"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.30.04 [ja]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: 
Subject: [Pce] Fw: I-D ACTION:draft-oki-pce-inter-layer-ext-00.txt 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

--------_4726F224E9C209E19F18_MULTIPART_MIXED_
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

Hi all,

A new draft on the inter-layer PCEP extentions has been published at
http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-ext-00.txt

This draft presents PCEP extensions for inter-layer traffic engineering
that satisfy the requirements described in inter-layer PCEP requirement
draft. 

Any comments and suggestions are highly appreciated.

Thank you.
Eiji

Forwarded by Eiji Oki <oki.eiji@lab.ntt.co.jp>
----------------------- Original Message -----------------------
 From:    Internet-Drafts@ietf.org
 To:      i-d-announce@ietf.org
 Date:    Tue, 23 Oct 2007 13:15:01 -0400
 Subject: I-D ACTION:draft-oki-pce-inter-layer-ext-00.txt 
----

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


	Title		: Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering 
	Author(s)	: E. Oki, et al.
	Filename	: draft-oki-pce-inter-layer-ext-00.txt
	Pages		: 1
	Date		: 2007-10-23
	
    The Path Computation Element (PCE) provides path computation 
    functions in support of traffic engineering in Multi-Protocol Label 
    Switching (MPLS) and Generalized MPLS (GMPLS) networks. 
     
    MPLS and GMPLS networks may be constructed from layered service 
    networks. It is advantageous for overall network efficiency to 
    provide end-to-end traffic engineering across multiple network 
    layers through a process called inter-layer traffic engineering. 
    PCE is a candidate solution for such requirements. 


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-ext-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@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-oki-pce-inter-layer-ext-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@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-oki-pce-inter-layer-ext-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.

--------------------- Original Message Ends --------------------

--
Eiji Oki, Ph. D.
Senior Research Engineer
NTT Network Service Systems Laboratories
3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan
Tel: +81-422-59-3441, Fax: +81-422-59-3787
E-mail: oki.eiji@lab.ntt.co.jp

--
$BBgLZ1Q;J(B
NTT$B%M%C%H%o!<%/%5!<%S%9%7%9%F%`8&5f=j(B
$B")(B180-8585 $BEl5~ETIpB"Ln;TNPD.(B3-9-11
Tel: 0422-59-3441, Fax: 0422-59-3787
E-mail: oki.eiji@lab.ntt.co.jp

--------_4726F224E9C209E19F18_MULTIPART_MIXED_
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
Content-Transfer-Encoding: 7bit

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <2007-10-23121756.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-oki-pce-inter-layer-ext-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-oki-pce-inter-layer-ext-00.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"
Content-Disposition: attachment;
	filename="draft-oki-pce-inter-layer-ext-00.txt"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain
Content-ID: <2007-10-23121756.I-D@ietf.org>


--OtherAccess--

--------_4726F224E9C209E19F18_MULTIPART_MIXED_
MIME-Version: 1.0
Content-Type: text/plain;
 charset="us-ascii"
Content-Disposition: attachment;
 filename=forward.txt
Content-Transfer-Encoding: 7bit

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------_4726F224E9C209E19F18_MULTIPART_MIXED_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--------_4726F224E9C209E19F18_MULTIPART_MIXED_--






From pce-bounces@lists.ietf.org Tue Oct 30 14:21:46 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Imvhz-0007Yg-Kl; Tue, 30 Oct 2007 14:20:59 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1Imvhy-0007YU-Pp
	for pce-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:20:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvhy-0007YM-GE
	for pce@ietf.org; Tue, 30 Oct 2007 14:20:58 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imvhx-0006i4-9l
	for pce@ietf.org; Tue, 30 Oct 2007 14:20:58 -0400
X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="183744693"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-5.cisco.com with ESMTP; 30 Oct 2007 11:20:56 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9UIKuuX021677
	for <pce@ietf.org>; Tue, 30 Oct 2007 11:20:56 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIKjUp019985
	for <pce@ietf.org>; Tue, 30 Oct 2007 18:20:54 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Oct 2007 11:20:53 -0700
Received: from [135.16.16.76] ([10.21.66.67]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 30 Oct 2007 11:20:53 -0700
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Transfer-Encoding: 7bit
Message-Id: <E910B96C-E57B-43B8-AD6E-C044C48CBCCE@cisco.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: pce@ietf.org
From: JP Vasseur <jvasseur@cisco.com>
Date: Tue, 30 Oct 2007 14:18:50 -0400
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 30 Oct 2007 18:20:53.0237 (UTC)
	FILETIME=[9B3C9A50:01C81B21]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=125; t=1193768456;
	x=1194632456; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jvasseur@cisco.com;
	z=From:=20JP=20Vasseur=20<jvasseur@cisco.com>
	|Subject:=20Next=20PCE=20WG=20meeting=20-=20IETF-70
	|Sender:=20; bh=oGQBnAOv3Gog/2/J1ZqJt3ETB60ovE/Lh2+6/O/yITQ=;
	b=LrsAor7zn3T65fPrGS+nmfyTaHEuTmtymqh1hzVzZehy69C8d0mNYtJR6hr4waVo3LbY8ByM
	Bs4DpQp8Qdvow5eV3K782EBX3e1IPFZCGBTFn+XecJKJ14OH0XxtCnX9ut0lCw8muiywd41F4z
	DFMp12ennJYG541VCNo19BCAI=;
Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: 
Subject: [Pce] Next PCE WG meeting - IETF-70
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org

Dear WG,

If you need a slot during the next PCE WG meeting in Vancouver,  
please send
us a request.

Thanks.

JP.


_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce



From pce-bounces@lists.ietf.org Wed Oct 31 17:14:30 2007
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1InKt0-0002J5-3P; Wed, 31 Oct 2007 17:14:02 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43)
	id 1InKsz-0002IL-3Y
	for pce-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 17:14:01 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1InKsy-0002I4-MV
	for pce@ietf.org; Wed, 31 Oct 2007 17:14:00 -0400
Received: from usaga04-in.huawei.com ([206.16.17.180]
	helo=usaga01-in.huawei.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InKsy-0000gQ-3T
	for pce@ietf.org; Wed, 31 Oct 2007 17:14:00 -0400
Received: from huawei.com (usaga04-in [172.18.9.16])
	by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0JQS00GX2OBAKP@usaga04-in.huawei.com> for
	pce@ietf.org; Wed, 31 Oct 2007 16:13:58 -0500 (CDT)
Received: from Lee736821 ([10.124.12.76])
	by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTPA id <0JQS00A9LOB3CH@usaga04-in.huawei.com> for
	pce@ietf.org; Wed, 31 Oct 2007 16:13:58 -0500 (CDT)
Date: Wed, 31 Oct 2007 15:13:51 -0600
From: Young Lee <ylee@huawei.com>
Subject: [Pce] Fw: I-D ACTION:draft-lee-pce-wson-routing and wavelength-00.txt
To: pce@ietf.org
Message-id: <006101c81c02$efee18d0$4c0c7c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Thread-index: AcgcAu9Nfj6JNThpSBmujhU+rt/TLQ==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336
Cc: 
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element  <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>,
	<mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1274602735=="
Errors-To: pce-bounces@lists.ietf.org

This is a multi-part message in MIME format.

--===============1274602735==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_7OuYb4pBNFYBuILV0yeIbA)"

This is a multi-part message in MIME format.

--Boundary_(ID_7OuYb4pBNFYBuILV0yeIbA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi All,

 

A new draft on WSON RWA PCEP requirements and extensions is now available
at:

 

http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing
<http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing%20and%20wave
length-00.txt>  and wavelength-00.txt

 

This draft is a follow-up with the Wavelength Switched Optical Networks
(WSON) framework draft and presents PCEP requirements and extensions for the
support of WSON Routing and Wavelength (RWA) process.  

 

We'd appreciate your comments and valuable suggestions. Thanks. 

 

Young and Greg

 

-----------------Original
E-mail-----------------------------------------------

*	To: i-d-announce at <mailto:i-d-announce@DOMAIN.HIDDEN>  ietf.org 
*	Subject: I-D ACTION:draft-lee-pce-wson-routing and wavelength-00.txt

*	From: Internet-Drafts at <mailto:Internet-Drafts@DOMAIN.HIDDEN>
ietf.org 
*	Date: Wed, 31 Oct 2007 15:15:02 -0400 
*	Cc: 
*	List-archive: < <http://www1.ietf.org/pipermail/i-d-announce>
http://www1.ietf.org/pipermail/i-d-announce> 
*	List-help: <mailto:i-d-announce-request@ietf.org?subject=help> 
*	List-id: i-d-announce.ietf.org 
*	List-post: <mailto:i-d-announce@ietf.org> 
*	List-subscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=subscribe> 
*	List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=unsubscribe> 
*	Reply-to: internet-drafts at <mailto:internet-drafts@DOMAIN.HIDDEN>
ietf.org 

  _____  

size=2 width="100%" align=center> 

*	To: i-d-announce at <mailto:i-d-announce@DOMAIN.HIDDEN>  ietf.org 
*	Subject: I-D ACTION:draft-lee-pce-wson-routing and wavelength-00.txt

*	From: Internet-Drafts <mailto:Internet-Drafts@DOMAIN.HIDDEN>  at
ietf.org 
*	Date: Wed, 31 Oct 2007 15:15:02 -0400 
*	Cc: 
*	List-archive: < <http://www1.ietf.org/pipermail/i-d-announce>
http://www1.ietf.org/pipermail/i-d-announce> 
*	List-help: <mailto:i-d-announce-request@ietf.org?subject=help> 
*	List-id: i-d-announce.ietf.org 
*	List-post: <mailto:i-d-announce@ietf.org> 
*	List-subscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=subscribe> 
*	List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=unsubscribe> 
*	Reply-to: internet-drafts <mailto:internet-drafts@DOMAIN.HIDDEN>  at
ietf.org 

  _____  

size=2 width="100%" align=center> 
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 
 
        Title          : Path Computation Element Communication Protocol
(PCEP) Requirements and Extensions for the Support of Wavelength Switched
Optical Networks 
        Author(s)      : Y. Lee, G. Bernstein
        Filename       : draft-lee-pce-wson-routing and wavelength-00.txt
        Pages          : 20
        Date           : 2007-10-31
        
 
   This memo provides application-specific PCEP requirements and 
   protocol enhancements for the support of Wavelength Switched Optical 
   Networks (WSON).  Lightpath provisioning in WSONs requires a routing 
   and wavelength assignment (RWA) process.  Different computational 
   architectures for the RWA process are given and the PCEP extensions 
   needed to support these architectures are defined. 
 
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing and
wavelength-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-lee-pce-wson-routing and wavelength-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-lee-pce-wson-routing and
wavelength-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.

 
<ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-wson-routing%20and%20wavel
ength-00.txt>
<ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-wson-routing%20and%20wavel
ength-00.txt> 

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
 

--Boundary_(ID_7OuYb4pBNFYBuILV0yeIbA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html>

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=ZH-CN link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>Hi All,</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>A new draft on WSON RWA PCEP requirements and
extensions is now available at:</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'><a
href="http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing%20and%20wavelength-00.txt">http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing
and wavelength-00.txt</a></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>This draft is a follow-up with the Wavelength
Switched Optical Networks (WSON) framework draft and presents PCEP requirements
and extensions for the support of WSON Routing and Wavelength (RWA) process. &nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>We&#8217;d appreciate your comments and valuable
suggestions. Thanks. </span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>Young and Greg</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span lang=EN-US style='font-size:
11.0pt;font-family:Arial'>-----------------Original E-mail-----------------------------------------------</span></font></p>

<ul type=disc>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>To</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: <a href="mailto:i-d-announce@DOMAIN.HIDDEN">i-d-announce at
     ietf.org</a> </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>Subject</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: I-D ACTION:draft-lee-pce-wson-routing and wavelength-00.txt </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>From</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: <a href="mailto:Internet-Drafts@DOMAIN.HIDDEN">Internet-Drafts at
     ietf.org</a> </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>Date</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: Wed, 31 Oct 2007 15:15:02 -0400 </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>Cc</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=DE
     style='font-size:11.0pt;font-family:Arial'>List-archive</span></font></i></em><font
     size=2 face=Arial><span lang=DE style='font-size:11.0pt;font-family:Arial'>:
     &lt;</span></font><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'><a
     href="http://www1.ietf.org/pipermail/i-d-announce"><span lang=DE>http://www1.ietf.org/pipermail/i-d-announce</span></a></span></font><font
     size=2 face=Arial><span lang=DE style='font-size:11.0pt;font-family:Arial'>&gt;
     </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>List-help</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: &lt;<a href="mailto:i-d-announce-request@ietf.org?subject=help">mailto:i-d-announce-request@ietf.org?subject=help</a>&gt;
     </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>List-id</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: i-d-announce.ietf.org </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>List-post</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: &lt;<a href="mailto:i-d-announce@ietf.org">mailto:i-d-announce@ietf.org</a>&gt;
     </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>List-subscribe</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: &lt;<a href="https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1.ietf.org/mailman/listinfo/i-d-announce</a>&gt;,
     &lt;<a href="mailto:i-d-announce-request@ietf.org?subject=subscribe">mailto:i-d-announce-request@ietf.org?subject=subscribe</a>&gt;
     </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>List-unsubscribe</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: &lt;<a href="https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1.ietf.org/mailman/listinfo/i-d-announce</a>&gt;,
     &lt;<a href="mailto:i-d-announce-request@ietf.org?subject=unsubscribe">mailto:i-d-announce-request@ietf.org?subject=unsubscribe</a>&gt;
     </span></font></li>
 <li class=MsoNormal><em><i><font size=2 face=Arial><span lang=EN-US
     style='font-size:11.0pt;font-family:Arial'>Reply-to</span></font></i></em><font
     size=2 face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:
     Arial'>: <a href="mailto:internet-drafts@DOMAIN.HIDDEN">internet-drafts at
     ietf.org</a> </span></font></li>
</ul>

<div class=MsoNormal align=center style='text-align:center'><font size=2
face=Arial><span lang=EN-US style='font-size:11.0pt;font-family:Arial'>

<hr<!--X-Head-of-Message-End--><!--X-Head-Body-Sep-Begin--> size=2 width="100%"
align=center>

</span></font></div>

<ul type=disc>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'><!--X-Head-Body-Sep-End--><!--X-Body-of-Message-->To</span></font></i></em><span
     lang=EN-US>: <a href="mailto:i-d-announce@DOMAIN.HIDDEN">i-d-announce at
     ietf.org</a> </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>Subject</span></font></i></em><span
     lang=EN-US>: I-D ACTION:draft-lee-pce-wson-routing and wavelength-00.txt </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>From</span></font></i></em><span
     lang=EN-US>: <a href="mailto:Internet-Drafts@DOMAIN.HIDDEN">Internet-Drafts
     at ietf.org</a> </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>Date</span></font></i></em><span
     lang=EN-US>: Wed, 31 Oct 2007 15:15:02 -0400 </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>Cc</span></font></i></em><span
     lang=EN-US>: </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span lang=DE
     style='font-size:12.0pt'>List-archive</span></font></i></em><span lang=DE>:
     &lt;</span><span lang=EN-US><a
     href="http://www1.ietf.org/pipermail/i-d-announce"><span lang=DE>http://www1.ietf.org/pipermail/i-d-announce</span></a></span><span
     lang=DE>&gt; </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>List-help</span></font></i></em><span
     lang=EN-US>: &lt;<a
     href="mailto:i-d-announce-request@ietf.org?subject=help">mailto:i-d-announce-request@ietf.org?subject=help</a>&gt;
     </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>List-id</span></font></i></em><span
     lang=EN-US>: i-d-announce.ietf.org </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>List-post</span></font></i></em><span
     lang=EN-US>: &lt;<a href="mailto:i-d-announce@ietf.org">mailto:i-d-announce@ietf.org</a>&gt;
     </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>List-subscribe</span></font></i></em><span
     lang=EN-US>: &lt;<a
     href="https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1.ietf.org/mailman/listinfo/i-d-announce</a>&gt;,
     &lt;<a href="mailto:i-d-announce-request@ietf.org?subject=subscribe">mailto:i-d-announce-request@ietf.org?subject=subscribe</a>&gt;
     </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>List-unsubscribe</span></font></i></em><span
     lang=EN-US>: &lt;<a
     href="https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1.ietf.org/mailman/listinfo/i-d-announce</a>&gt;,
     &lt;<a href="mailto:i-d-announce-request@ietf.org?subject=unsubscribe">mailto:i-d-announce-request@ietf.org?subject=unsubscribe</a>&gt;
     </span></li>
 <li class=MsoNormal><em><i><font size=3 face="Times New Roman"><span
     lang=EN-US style='font-size:12.0pt'>Reply-to</span></font></i></em><span
     lang=EN-US>: <a href="mailto:internet-drafts@DOMAIN.HIDDEN">internet-drafts
     at ietf.org</a> </span></li>
</ul>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr<!--X-Head-of-Message-End--><!--X-Head-Body-Sep-Begin--> size=2 width="100%"
align=center>

</span></font></div>

<pre><font size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'><!--X-Head-Body-Sep-End--><!--X-Body-of-Message-->A New Internet-Draft is available from the on-line Internet-Drafts </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>directories.</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Path Computation Element Communication Protocol (PCEP) Requirements and Extensions for the Support of Wavelength Switched Optical Networks </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Y. Lee, G. Bernstein</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : draft-lee-pce-wson-routing and wavelength-00.txt</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 20</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2007-10-31</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp; This memo provides application-specific PCEP requirements and </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;protocol enhancements for the support of Wavelength Switched Optical </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;Networks (WSON).&nbsp; Lightpath provisioning in WSONs requires a routing </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;and wavelength assignment (RWA) process.&nbsp; Different computational </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;architectures for the RWA process are given and the PCEP extensions </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;needed to support these architectures are defined. </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>A URL for this Internet-Draft is:</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'><a
href="http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing">http://www.ietf.org/internet-drafts/draft-lee-pce-wson-routing</a> and wavelength-00.txt</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>To remove yourself from the I-D Announcement list, send a message to </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>i-d-announce-request at ietf.org with the word unsubscribe in the body of </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>the message. </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>You can also visit <a
href="https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1.ietf.org/mailman/listinfo/I-D-announce</a> </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>to change your subscription settings.</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>Internet-Drafts are also available by anonymous FTP. Login with the </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>username &quot;anonymous&quot; and a password of your e-mail address. After </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>logging in, type &quot;cd internet-drafts&quot; and then </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&quot;get draft-lee-pce-wson-routing and wavelength-00.txt&quot;.</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>A list of Internet-Drafts directories can be found in</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'><a
href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>or <a
href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a></span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>Internet-Drafts can also be obtained by e-mail.</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>Send a message to:</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailserv at ietf.org.</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>In the body type:</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE /internet-drafts/draft-lee-pce-wson-routing and wavelength-00.txt&quot;.</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document in</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using the &quot;mpack&quot; utility.&nbsp; To use this</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command &quot;ENCODING mime&quot; before the &quot;FILE&quot;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode the response(s), you will need &quot;munpack&quot; or</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail reader.&nbsp; Different MIME-compliant mail readers</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior, especially when dealing with</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;multipart&quot; MIME messages (i.e. documents which have been split</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages), so check your local documentation on</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these messages.</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>Below is the data which will enable a MIME compliant mail reader</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>implementation to automatically retrieve the ASCII version of the</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>Internet-Draft.</span></font></pre>

<p class=MsoNormal><font size=3 face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt'><a
href="ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-wson-routing%20and%20wavelength-00.txt">&lt;ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-wson-routing%20and%20wavelength-00.txt&gt;</a>
</span></font></p>

<pre><font size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>_______________________________________________</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>I-D-Announce mailing list</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>I-D-Announce at ietf.org</span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'><a
href="https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1.ietf.org/mailman/listinfo/i-d-announce</a></span></font></pre><pre><font
size=3 face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></pre><!--X-Body-of-Message-End--><!--X-MsgBody-End--><!--X-Follow-Ups--></div>

</body>

</html>

--Boundary_(ID_7OuYb4pBNFYBuILV0yeIbA)--



--===============1274602735==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

--===============1274602735==--