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

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

Hi JP,

Thanks for the clarifications.

Best regards
Fabien


> -----Message d'origine-----
> De : JP Vasseur [mailto:[e-mail]]
> Envoyé : mardi 26 février 2008 05:24
> À : [e-mail]
> Cc : [e-mail]
> Objet : Re: [Pce] FW: I-D Action:draft-ietf-pce-pcep-10.txt
> 
> 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]
https://www.ietf.org/mailman/listinfo/pce