Subject: [Pce] Length of Flag Field in RP Object

From: "S.SenthilKumar (Huawei)" <[email-masked]>
Date: Wed, 22 Oct 2008 15:05:35 +0530

Dear All
 
The following Section is taken from draft-ietf-pce-pcep-16.txt
 
In this context, the length of the Flag field is not clear in the text. 
 
>From the figure, Flags field is 26 bits and the rest 6 bits are defined as
Pri (Priority) - 3 bits, R (Reoptimization) - 1 bit, B (Bi-directional) - 1
bit and O (strict/loose) - 1 bit.
 
But in the text, 
 
a) Flags field is mentioned as 24 bit
b) Pri, R, B and O fields are part of the flags and is miss-leading

---------- Text of concern -----------------------------
   Flags (24 bits)
 
   The following flags are currently defined:
---------------------------------------------------------------
 
Please clarify.
 
Best regards
S.SenthilKumar

 
7.4.  RP Object
 
   The RP (Request Parameters) object MUST be carried within each PCReq
   and PCRep messages and MAY be carried within PCNtf and PCErr
   messages.  The RP object is used to specify various characteristics
   of the path computation request.
 
   The P flag of the RP object MUST be set in PCReq and PCReq messages
   and MUST be cleared in PCNtf and PCErr messages.  If the RP objet is
   received with the P flag set incorrectly according to the rules
   states above, the receiving peer MUST send a PCErr message with
   Error-type=10 and Error-value=1.  The corresponding path computation
   request MUST be cancelled by the PCE without further notification.
 
7.4.1.  Object Definition
 
   RP Object-Class is to be assigned by IANA (recommended value=2)
 
   RP Object-Type is to be assigned by IANA (recommended value=1)

   The format of the RP object body is as follows:
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Flags                    |O|B|R| Pri |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Request-ID-number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                  Figure 10: RP object body format
 
   The RP object body has a variable length and may contain additional
   TLVs.  No TLVs are currently defined.
 
   Flags (24 bits)
 
   The following flags are currently defined:
 
   o  Pri (Priority - 3 bits): the Priority field may be used by the
      requesting PCC to specify to the PCE the request's priority from 1
      to 7.  The decision of which priority should be used for a
      specific request is of a local matter and MUST be set to 0 when
      unused.  Furthermore, the use of the path computation request
      priority by the PCE's scheduler is implementation specific and out
      of the scope of this document.  Note that it is not required for a
      PCE to support the priority field: in this case, it is RECOMMENDED
      that the PCC set the priority field to 0 in the RP object.  If the
      PCE does not take into account the request priority, it is
      RECOMMENDED to set the priority field to 0 in the RP object
      carried within the corresponding PCRep message, regardless of the
      priority value contained in the RP object carried within the
      corresponding PCReq message.  A higher numerical value of the
      priority field reflects a higher priority.  Note that it is the
      responsibility of the network administrator to make use of the
      priority values in a consistent manner across the various PCCs.
      The ability of a PCE to support request prioritization MAY be
      dynamically discovered by the PCCs by means of PCE capability
      discovery.  If not advertised by the PCE, a PCC may decide to set
      the request priority and will learn the ability of the PCE to
      support request prioritization by observing the Priority field of
      the RP object received in the PCRep message.  If the value of the
      Pri field is set to 0, this means that the PCE does not support
      the handling of request priorities: in other words, the path
      computation request has been honoured but without taking the
      request priority into account.
 
   o  R (Reoptimization - 1 bit): when set, the requesting PCC specifies
      that the PCReq message relates to the reoptimization of an
      existing TE LSP.  For all TE LSPs except 0-bandwidth LSPs, when
      the R bit is set, an RRO (see Section 7.10) MUST be included in
      the PCReq message to show the path of the existing TE LSP.  Also,
      for all TE LSPs except 0-bandwidth LSPs, then the R bit is set,
      the existing bandwidth of the TE LSP to be reoptimized MUST be
      supplied in a BANDWIDTH object (see Section 7.7).  This BANDWIDTH
      object is in addition to the instance of that object used to
      describe the desired bandwidth of the reoptimized LSP.  For
      0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the
      characteristics of the existing TE LSP are optional.
 
   o  B (Bi-directional - 1 bit): when set, the PCC specifies that the
      path computation request relates to a bidirectional TE LSP that
      has the same traffic engineering requirements including fate
      sharing, protection and restoration, LSRs, TE Links, and resource
      requirements (e.g., latency and jitter) in each direction.  When
      cleared, the TE LSP is unidirectional.
 
   o  O (strict/loose - 1 bit): when set, in a PCReq message, this
      indicates that a loose path is acceptable.  Otherwise, when
      cleared, this indicates to the PCE that a path exclusively made of
      strict hops is required.  In a PCRep message, when the O bit is
      set this indicates that the returned path is a loose path,
      otherwise (the O bit is cleared), the returned path is made of
      strict hops.
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Oct 2008 14:02:10 +0100

Hi,

Good catch, thanks.

The figure is correct.

The text should actually say
     Flags (32 bits)
as the Pri, O, B, and R flags are part of the flags field

We'll either fix this in the next revision or in the RFC Editor process.

Thanks,
Adrian

----- Original Message ----- 
From: "S.SenthilKumar (Huawei)" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 22, 2008 10:35 AM
Subject: [Pce] Length of Flag Field in RP Object

>   The following flags are currently defined:

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