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

[JP Vasseur <[e-mail]>]

Hi Fabien,

See in line and thanks for the series of useful comments that you have
provided during the protocol specification.


> From: Fabien VERHAEGHE <[e-mail]>
> Reply-To: <[e-mail]>
> Date: Mon, 25 Feb 2008 13:01:05 +0100
> To: 'JP Vasseur' <[e-mail]>, <[e-mail]>
> Subject: RE: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt
> 
> Hi JP 
> 
> Thanks for the reply.
> See inline...
> 
>> -----Message d'origine-----
>> De : JP Vasseur [mailto:[e-mail]]
>> Envoyé : jeudi 21 février 2008 20:02
>> À : [e-mail]; [e-mail]
>> Objet : Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt
>> 
>> Hi Fabien,
>> 
>> Thanks for your review - Comments in line,
>> 
>> 
>>> From: Fabien VERHAEGHE <[e-mail]>
>>> Reply-To: <[e-mail]>
>>> Date: Wed, 20 Feb 2008 17:08:28 +0100
>>> To: 'JP Vasseur' <[e-mail]>, <[e-mail]>
>>> Subject: 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.
>> 
>> It is, as mentioned in the text above.
>> 
> 
> Sorry but I'm not sure to understand your answer.
> Can you confirm that we no longer send PCErr message upon receipt of a
> malformed message once the session is up?
> We just send a close message reason 3.

JP> We only clarified that PCErr were not only sent in case of protocol
errors. Back to your example, nothing has been changed:

* During the session establishment *

   If a malformed message is received, the receiving PCEP peer MUST send
   a PCErr message with Error-type=1, Error-value=1.


where:

Error-Type    Meaning
   1          PCEP session establishment failure
              Error-value=1: reception of an invalid Open message or
                             a non Open message.


* As you said, when the PCEP Session is UP *

As mentioned in the FSM:

   If a malformed message is received, the system terminates the PCEP
   session according to the procedure defined in Section 6.8, releases
   the PCEP resources for that PCEP peer, closes the TCP connection and
   moves to the Idle State.

We're in sync, in this case (PCEP Session UP), we only send a CLOSE.

The example " e.g., reception of a malformed message" is not a good one
indeed, good catch. Text changed:

OLD:
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, ...).  The Message-Type field of the PCEP
   common header is set to 6 (To be confirmed by IANA).


NEW:
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.,
   capability not supported, reception of a message with a
   mandatory missing object, policy violation, unexpected message,
   unknown request reference, ...).  The Message-Type field of the PCEP
   common header is set to 6 (To be confirmed by IANA).

> 
> 
> 
>>  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.
>> 
>> JP> Good catch indeed, thanks.
>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> 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.
>> 
>> I think that we still need the ConnecRetry mechanism on top of TCP.
>> Whether
>> it should be configurable is debatable. We should be careful not to add
>> too
>> many configurable timers when using a value other than the default is not
>> likely though.
>> 
>> Other opinions?
>> 
> 
> Well my opinion is that there is no interop issue in making the parameters
> configurable and the whole mechanism optional.
> So I guess it is really an implementation choice.
> I would personally just have liked to see this mention in the draft.
> But I don't see letting the text as it is as a big issue.

The idea was to not impose the make these parameters configurable. According
to the spec they are architectural constants.

> 
>>> 
>>> ------------------------------
>>> 
>>> 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 issue with that approach is that the constraints for the primary and
>> secondary paths MUST be identical and there are circumstances where this
>> is
>> not desirable. Thus, we need a more generic mechanism to handle those
>> common
>> cases. Should the parameters be identical, do you think that the
>> "overhead"
>> is so important to justify the introduction of another mechanism?
>> 
> 
> I did not mean to replace the whole SVEC mechanism by the new proposed TLV
> cause I agree with you that it is good to have such generic mechanism.
> 

Understood.

> I just wanted to bring the attention to the WG about the extra overhead
> problem cause I find it personally weird to duplicate the information for
> such regular case.
> 
> I may be wrong but it seems to me that most of the time working and
> protecting path will have the same characteristics.

That REALLY depends but I do not think that this is always the case for
sure.

> So if you imagine PCE application that always request both a working and a
> protecting path (e.g. PBT) you will actually double the bandwidth used by
> PCEP Path Request.

With is not really an issue compared to the bandwidth used for protection in
the network ;-))

> And it can be more significant in case of P2MP or GCO for instance where
> PCEP message may be quite large.
> 
> Anyway if the WG is Ok with that I'm obviously fine too.

And I'm not saying that this would not help in some cases but .... Because
we have a generic mechanism that covers both cases, with little overhead, I
am always leaning toward the simplest most generic mechanism as opposed to
two ways to so the same thing in some cases. If it turns out that this
creates too much overhead in specific situation (e.g, large P2MP TE LSPS
with protection, ...), if needed, the extensions could be defined in another
document.

Agree?

Thanks for the careful review.

Cheers.

JP.

> 
>>> 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.
>> 
>> Which makes the processing even more complex.
>> 
>> If OK with I think that it is preferable to keep the current simple and
>> generic mechanism here.
>> 
>>> 
>>> Note that this would partially solved some issue raised by
>>> draft-nishioka-pce-svec-list-01.txt.
>>> 
>> 
>> Thanks.
>> 
>> JP.
>> 
>>> 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