Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt

["Fabien VERHAEGHE" <[e-mail]>]

Hi JP,

Another quick comment on PCEPv10

section 7.5

The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in
section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying
the TLV length (length of the value portion in bytes) followed by a fixed
length value field of 32-bit flags field.

TYPE: To be assigned by IANA (suggested value=1)
LENGTH: 1
VALUE: 32-bit flags field

LENGTH is 4 not 1.

Best regards
Fabien


-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Fabien
VERHAEGHE
Envoyé : mercredi 20 février 2008 17:08
À : 'JP Vasseur'; [e-mail]
Objet : Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt

Hi JP,

Here are few comments on version 10 of PCEP.


4.2.5

The PCEP Error message (also referred to as a PCErr message) is sent
   in several situations: when a protocol error condition is met or when
   the request is not compliant with the PCEP specification (e.g.,
   reception of a malformed message, ...

FV: If I understand correctly receipt of a malformed message is no longer an
example of PCEP error message. Malformed message is only notify using a
Close message reason 3.
If I'm correct Figure 6 should also be modified.

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

7.8.  METRIC Object

The presence of two METRIC objects of the same type with a different
   value of the B-Flag in a PCEReq message is allowed.  Furthermore, it
   is also allowed to insert in a PCReq message two METRIC objects with
   the same type that have both their B-Flag cleared: in this case, an
   objective function must be used by the PCE to solve a multi-parameter
   constraint problem.

FV: I think it should be 

The presence of two METRIC objects of the same type with a different
   value of the B-Flag in a PCEReq message is allowed.  Furthermore, it
   is also allowed to insert in a PCReq message two METRIC objects with
   
   **DIFFERENT** types that have both their B-Flag cleared: in this case, an

   objective function must be used by the PCE to solve a multi-parameter
   constraint problem.


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

PCEP Finite State Machine

Maybe I'm a little late for this comment but I'm wondering what is the
purpose of ConnectRetry timer. 
TCP already takes care of retransmissions.
Besides with a connect timer of 60s and ConnectMaxRetry of 5 it can take
like 30minutes before actually notify the PCC application that the PCEP
session establishment fails. Isn't it to long?

I would suggest at least to state that the ConnectRetry mechanism is
optional and make the connect and ConnectMaxRetry parameter configurable.

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

Requesting protecting LSP.

During implementation we went into a case where we want to establish a
working and a protecting LSP (link or node diverse).
With current specification it means we have to create 2 identical requests
associated with a SVEC.

It seems a little bit complex for such simple and regular case. Besides it
entails some unnecessary PCEP message overhead because of the duplicate
information.

I think it would make sense to add a TLV in RP object to request 1 (or more)
link/SRLG/node diverse protecting path(s).
The 2 (or n) result paths can then be inserted associated to the same RP
object in the PCRep since it is already authorized by PCRep BNF format.
Note that it may require another TLV (or a new bit) in the RP of the PCRep 
to distinguish between working and protecting path in the case that a PCC 
request a protecting path for a request that also contains a Load Balancing
object.

Note that this would partially solved some issue raised by
draft-nishioka-pce-svec-list-01.txt.

Best regards
Fabien

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de JP
Vasseur
Envoyé : mardi 12 février 2008 00:03
À : [e-mail]
Objet : [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt

> Dear WG,
> 
> Please find below the changes in the revision 10 of PCEP. Special thanks
to
> Adrian who made a very detailed review.
> 
> 
> 1) Lots of edits, clarifications, ....
> 2) Figure 1 was a bit ambiguous, thus we slightly changed it to reflect
the
> fact that the first message sent after the establishment of a PCEP session
is
> always an Open message as stated in several sections including the FSM.
> 3) We clarified in the FSM that in OpenWait state, the reception of a non
Open
> object triggered an error condition
> 4) Clarification:
> OLD: Error-Type=1 Error-value=1: reception of a malformed message
> NEW: Error-Type=1 Error-value=1: reception of an invalid Open message or
>                   a non Open message.
> 5) figure 6: example of PCErr has been changed (Policy violation => non
> supported object).
> 6) Clarification on PCErr
> OLD TEXT: PCEP Error messages are sent when a protocol error condition is
met
> (e.g. unknown object, non supported object, policy violation, ...).
> 
> NEW TEXT: The PCEP Error message (also referred to as a PCErr message) is
sent
> in several situations: when a protocol error condition is met or when the
> request is not compliant with the PCEP specification (e.g., reception of a
> malformed message, reception of a message with a mandatory missing object,
> policy violation, unexpected message, unknown request reference, ...).
> 
> 7) BNF Change for PCEReq
> 
> OLD:
> <PCReq Message>::= <Common Header>
>                    [<SVEC-list>]
>                    <request-list>
> 
> where:
>    <svec-list>::=<SVEC>[<svec-list>]
>    <request-list>::=<request>[<request-list>]
>    
>    <request>::= <RP>
>                 <END-POINTS>
>                 [<LSPA>]
>                 [<BANDWIDTH>]
>                 [<BANDWIDTH>]
>                 [<metric-list>]
>                 [<RRO>]
>                 [<IRO>]
>                 [<LOAD-BALANCING>]
> where: 
> 
> <metric-list>::=<METRIC>[<metric-list>]
> 
> NEW:
> <PCReq Message>::= <Common Header>
>                    [<SVEC-list>]
>                    <request-list>
> 
> where:
>    <svec-list>::=<SVEC>[<svec-list>]
>    <request-list>::=<request>[<request-list>]
>    
>    <request>::= <RP>
>                 <END-POINTS>
>                 [<LSPA>]
>                 [<BANDWIDTH>]
>                 [<metric-list>]
>                 [<RRO>[<BANDWIDTH>]]
>                 [<IRO>]
>                 [<LOAD-BALANCING>]
> where: 
> 
> <metric-list>::=<METRIC>[<metric-list>]
> 
> 8) Text added in section 6.8: If more than one CLOSE object is present,
the
> first MUST be processed and subsequent objects ignored.
> 
> 9) In several places:
> 
> OLD: Unassigned flags MUST be set to zero on transmission.
> 
> OLD: Unassigned flags MUST be set to zero on transmission and MUST be
ignored
> on receipt.
> 
> 10) Keepalive timer=0 condition.
> 
> OLD: DeadTimer (8 bits): specifies the amount of time after the expiration
of
> which the PCEP peer can declare the session with the sender of the Open
> message down if no PCEP message has been received. The DeadTimer MUST be
set
> to 0 if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer
is 4
> times the value of the Keepalive.
> 
> NEW:
> DeadTimer (8 bits): specifies the amount of time after the expiration of
which
> the PCEP peer can declare the session with the sender of the Open message
down
> if no PCEP message has been received. The DeadTimer SHOULD be set to 0 and
> MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the
> DeadTimer is 4 times the value of the Keepalive.
> 
> 
> 11) SID: Text added: " There is one SID number in each direction."
> 
> 12) 
> 
> OLD: The PCNtf message MUST carry at least one NOTIFICATION object and may
> contain several NOTIFICATION objects
> 
> NEW: The PCNtf message MUST carry at least one NOTIFICATION object and MAY
> contain several NOTIFICATION objects
> 
> 13) Clarification
> 
> The PCEP Error message (also referred to as a PCErr message) is sent in
> several situations: when a protocol error condition is met or when the
request
> is not compliant with the PCEP specification (e.g., reception of a
malformed
> message, reception of a message with a mandatory missing object,  policy
> violation, unexpected message, unknown request reference, ...).
> 
> 14) BNF of PCErr fixed
> 
> Suppose I want to report three error conditions:
>    a. Requests 1 and 2 with errors p and q
>    b. Unassociated errors r and s
>    c. Request 3 with error t
>    If I report them in this order, it will appear that errors r and s
>    apply only to requests 1 and 2
>    I am forced to report condition b before conditions a or c.
> 
> 
> BNF of PCErr fixed:
> 
> OLD
> 
> <PCErr Message> ::= <Common Header>
>                     <error-list>
>                     [<Open>]
>                  
> <error-list>::=<error>[<error-list>]
> <error>::=[<request-id-list>]
>            <error-obj-list>
>           
> <request-id-list>::=<RP>[<request-id-list>]
> 
> <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
> 
> NEW
> 
> <PCErr Message> ::= <Common Header>
>                        ( <error-object-list> [<Open>] ) | <error>
>                        [<error-list>]
> 
>    <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
>    <error>::=[<request-id-list>]
>               <error-obj-list>
>    <request-id-list>::=<RP>[<request-id-list>]
>    <error-list>::=<error>[<error-list>]
> 
> 
> 15) Clarification
> 
> OLD:
> 
>  o  P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
>       specify in a PCReq message sent to a PCE whether the object must
>       be taken into account by the PCE during path computation or is
>       just optional.  When the P flag is set, the object MUST be taken
>       into account by the PCE. Conversely, when the P flag is cleared,
>       the object is optional and the PCE is free to ignore it if not
>       supported.
> 
> NEW:
> 
>  o  P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
>       specify in a PCReq message sent to a PCE whether the object must
>       be taken into account by the PCE during path computation or is
>       just optional.  When the P flag is set, the object MUST be taken
>       into account by the PCE. Conversely, when the P flag is cleared,
>       the object is optional and the PCE is free to ignore it.
> 
> Could be because not supported, or easier to handle the request this way,
...
> 
> 16) Slightly new format for the RP object:
> 
> OLD:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Reserved   |               Flags               |O|B|R| Pri |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Request-ID-number                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    //                      Optional TLV(s)                        //
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> NEW:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Flags                      |O|B|R| Pri |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Request-ID-number                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    //                      Optional TLV(s)                        //
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> 
> 17) 
> 
> OLD: The ability of a PCE to support request prioritization may be
dynamically
> discovered by the PCCs by means of PCE capability discovery.
> 
> NEW: The ability of a PCE to support request prioritization MAY be
dynamically
> discovered by the PCCs by means of PCE capability discovery.
> 
> 18)
> 
> In the case of a reoptimization, text has been added to indicate that the
RRO
> but also the BANDWIDTH of the existing TE LSP MUST be supplied.
> 
> 19) 
> 
> OLD:
> The same Request-ID-number may be used for path computation requests sent
to
> different PCEs.
> 
> NEW:
> The same Request-ID-number MAY be used for path computation requests sent
to
> different PCEs.
> 
> 20)
> 
> A registry has been created in the IANA section for the Nature of Issue
field
> (NI) present in the NO-PATH object.
> 
> 21) 
> 
> Flags/Field in the NO-PATH object.
> 
> OLD
> When the C bit is set, the NI field value MUST be 0x00.
> 
> NEW
> The C flag has no meaning and is ignored unless the NI field is set to
0x00
> 
> 22) 
> 
> A registry has been created in the IANA section for T fied (Type) and the
Flag
> field of the METRIC Object.
> 
> 23)
> 
> A registry has been created in the IANA section for Flag field of the RP
> Object 
> 
> 24) Text changed for the METRIC object.
> 
> OLD
> 
>    In a PCReq message the presence of multiple METRIC objects can be
>    used to specify a multi-parameters (e.g. a metric may be a constraint
>    or a parameter to minimize/maximize) objective function or multiple
>    bounds for different constraints where at most one METRIC object must
>    be used to indicate the metric to optimize (B-flag is cleared): the
>    other METRIC object MUST be used to reflect bound constraints (B-Flag
>    is set).  If a PCReq message is received that contains two METRIC
>    objects with the B flag set, the receiving peer MUST send a PCErr
>    message with Error-type=10 and Error-value=2.
> 
> Adrian> The two paragraphs above are on the same material but may
contradict.
>    You need to allow:
>    - multiple objects each with a different metric type
>    - declare a rule if there are two with the same type
>    Why would you allow two with the same type one with the B flag set
>    and one without? You cannot both minimize and only minimize below a
>    bound.
> 
> JP> You can ... "Find the minimum TE cost but it has to be below X
> (constraint).
> 
>    Conversely, why do you prohibit a slution that minimizes more than
>    one metric? Of course, sometimes that can't be solved (conflicting
>    constraints), but sometimes it can be used to select between equal
>    cost paths. The way to resolve the contention, is to give the metrics
>    priorities, but that is cutting into the objective function
>    definitions. Therefore, the correct answer is to allow multiple
>    metric objects with the B flag set, and allow the objective function
>    to decide whether to reject the case, or to process it.
> 
> JP> Yes indeed. Furthermore we could have more than two METRIC
> object with the B Flag set (multiple bounds) and we could have the same
> METRIC object twice with different values for the B-Flag.
> 
> NEW TEXT:
> 
> We removed: " In a PCReq message the presence of multiple METRIC objects
can
> be used to specify a multi-parameters (e.g. a metric may be a constraint
or a
> parameter to minimize/maximize) objective function or multiple bounds for
> different constraints where at most one METRIC object must be used to
indicate
> the metric to optimize (B-flag is cleared): the other METRIC object MUST
be
> used to reflect bound constraints (B-Flag is set). If a PCReq message is
> received that contains two METRIC objects with the B flag set, the
receiving
> peer MUST send a PCErr message with Error-type=10 and Error-value=2."
> 
> We added: "The presence of two METRIC objects of the same type with a
> different value of the B-Flag in a PCEReq message is allowed. Furthermore,
it
> is also allowed to insert in a PCReq message two METRIC objects with the
same
> type that have both their B-Flag cleared: in this case, an objective
function
> must be used by the PCE to solve a multi-parameter constraint problem."
> 
> The following Error-value has been removed:
> 
> 10         Reception of an invalid object
>                Error-value=2: reception of a PCReq message with two METRIC
>                objects with B-flag set.
> 
> 25)
> 
> We have renamed RRO: Route Record Object => Reported Route Object
> 
> 26)
> 
> Clarification added:
> 
> OLD: Subobjects The IRO is made of sub-object(s) identical to the ones
>    defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs.
> 
> NEW: Subobjects The IRO is made of sub-object(s) identical to the ones
>    defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject
type
> is identical to the subobject type defined in the related documents.
> 
> 27) Text Changed:
> 
>    In Section 7.13 (SVEC) we had: " When a PCE receives a path computation
>    request that cannot be satisfied (for example because the PCReq
>    message contains an object with the P bit set that is not supported),
>    the PCE sends a PCErr message for this request (see Section 7.2, the
>    PCE MUST cancel the whole set of related path computation requests
>    and MUST send a PCErr message with Error-Type="Synchronized path
>    computation request missing"."
> 
> Then in section 7.14:
> 
>          Notification-type=1 - Pending Request cancelled
>          Notification-value=2: PCE cancels a set of pending request(s).
>          A Notification-type=1, Notification-value=2 indicates that the
>          PCE wants to inform a PCC of the cancellation of a set of
>          pending request(s).  Such event could be triggered because of
>          PCE overloaded state or because of missing path computation
>          requests that are part the set of synchronized path computation
>          requests.
> 
> In case of a missing request listed in the SVEC we want to rely on a PCErr
> only.
> 
> Furthermore we have defined another Notificaton-Type for PCE Overloaded
state
> (Notification-type=2: Overloaded PCE).
> 
> So we changed the text in the following way:
> 
> OLD: 
> o  Notification-type=1: Pending Request cancelled
> Notification-value=2: PCE cancels a set of pending request(s).
> A Notification-type=1, Notification-value=2 indicates that the
> PCE wants to inform a PCC of the cancellation of a set of
> pending request(s).  Such event could be triggered because of
> PCE overloaded state or because of missing path computation
> requests that are part the set of synchronized path computation
> requests.  A NOTIFICATION object with Notification-type=1,
> Notification-value=2 is carried within a PCNtf message sent by
> a PCE to a PCC.  The RP object corresponding to the cancelled
> request MUST also be present in the PCNtf message.  Multiple RP
> objects may be carried within the PCNtf message in which case
> the notification applies to all of them.  If such notification
> is received by a PCE from a PCC, the PCE MUST silently ignore
> the notification and no errors should be generated.
> 
> NEW:
> o  Notification-type=1: Pending Request cancelled
> Notification-value=2: PCE cancels a set of pending requests. A
> Notification-type=1, Notification-value=2 indicates that the PCE wants to
> inform a PCC of the cancellation of a set of pending requests. A
NOTIFICATION
> object with Notification-type=1, Notification-value=2 is carried within a
> PCNtf message sent by a PCE to a PCC. The RP object corresponding to the
> cancelled request MUST also be present in the PCNtf message. Multiple RP
> objects may be carried within the PCNtf message in which case the
notification
> applies to all of them. If such notification is received by a PCE from a
PCC,
> the PCE MUST silently ignore the notification and no errors should be
> generated.
> 
> Indeed for the SVEC case, we use PCErr, and for the PCE overloaded case,
we
> use Notification-type=2, Notification-value=1.
> 
> 28)  MUST => SHOULD
> 
> OLD:
> Notification-value=2: A Notification-type=2, Notification-value=2
indicates
> that the PCE is no longer in congested state and is available to process
new
> path computation requests. An implementation MUST make sure that a PCE
sends
> such notification to every PCC to which a Notification message (with
> Notification-type=2, Notification-value=1) has been sent unless an
> OVERLOADED-DURATION TLV has been included in the corresponding message and
the
> PCE wishes to wait for the expiration of that period of time before
receiving
> new requests. 
> 
> NEW: 
> Notification-value=2: A Notification-type=2, Notification-value=2
indicates
> that the PCE is no longer in congested state and is available to process
new
> path computation requests. An implementation SHOULD make sure that a PCE
sends
> such notification to every PCC to which a Notification message (with
> Notification-type=2, Notification-value=1) has been sent unless an
> OVERLOADED-DURATION TLV has been included in the corresponding message and
the
> PCE wishes to wait for the expiration of that period of time before
receiving
> new requests. 
> 
> A PCE may intentionally not willing to share its cleared overloaded state
to
> some PCCS. 
> 
> 29)
> 
> We removed (see RFC5088 and RFC5089):
> 
> Alternatively, PCE may decide to signal its (non) overloaded
>          state using a IGP-based notification mechanism as defined in
>          [I-D.ietf-pce-disco-proto-isis]and
>          [I-D.ietf-pce-disco-proto-ospf].  A PCE may also decide to
>          signal its overloaded state using PCEP and its no longer
>          overloaded state using an IGP-based notification and vice-
>          versa.
> 
> 30)
> 
> OLD:
> 10         Reception of a malformed object
>               Error-value=1: reception of an object with P flag not set
>                              although the P-flag must be set according to
>                              this specification.
>                Error-value=2: reception of a PCReq message with two METRIC
>                               objects with B-flag set.
> 
> NEW:
> 10         Reception of an invalid object
>                Error-value=1: reception of an object with P flag not set
>                               although the P-flag must be set according to
>                               this specification.
>                
> 
> 31) Text Added in the IANA section:
> 
> The allocation policy for each new registry is by IETF Consensus: new
values
> are assigned through the IETF consensus process (see [RFC2434]).
Specifically,
> new assignments are made via RFCs approved by the IESG. Typically, the
IESG
> will seek input on prospective assignments from appropriate persons (e.g.,
a
> relevant Working Group if one exists).
> 
> 
> Thanks.
> 
> JP, JL et al.
> 
> 
> ------ Forwarded Message
>> From: <[e-mail]>
>> Reply-To: <[e-mail]>
>> Date: Mon, 11 Feb 2008 12:15:02 -0800 (PST)
>> To: <[e-mail]>
>> Cc: <[e-mail]>
>> Subject: I-D Action:draft-ietf-pce-pcep-10.txt
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Path Computation Element Working Group
of
>> the 
>> IETF.
>> 
>> 
>> Title           : Path Computation Element (PCE) Communication Protocol
>> (PCEP)
>> Author(s)       : A. Ayyangar, et al.
>> Filename        : draft-ietf-pce-pcep-10.txt
>> Pages           : 76
>> Date            : 2008-02-11
>> 
>> This document specifies the Path Computation Element Communication
>> Protocol (PCEP) for communications between a Path Computation Client
>> (PCC) and a Path Computation Element (PCE), or between two PCEs.
>> Such interactions include path computation requests and path
>> computation replies as well as notifications of specific states
>> related to the use of a PCE in the context of Multiprotocol Label
>> Switching (MPLS) and Generalized (GMPLS) Traffic Engineering.  PCEP
>> is designed to be flexible and extensible so as to easily allow for
>> the addition of further messages and objects, should further
>> requirements be expressed in the future.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-10.txt
>> 
>> To remove yourself from the I-D Announcement list, send a message to
>> [e-mail] with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>> 
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-ietf-pce-pcep-10.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:
>> [e-mail].
>> In the body type:
>> "FILE /internet-drafts/draft-ietf-pce-pcep-10.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.
>> Content-Type: text/plain
>> Content-ID: <2008-02-11120708.I-D\@ietf.org>
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> http://www.ietf.org/mailman/listinfo/i-d-announce
> 
> ------ End of Forwarded Message

------ End of Forwarded Message

_______________________________________________
Pce mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pce