Subject: [Pce] Clearing your Discuss on draft-ietf-pce-pcep-14.txt

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Sep 2008 12:26:01 +0100

Hi Magnus,

Please see http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-14.txt
and in line.
If you are running wdiff, compare with v12.

Thanks,
Adrian

===

> 1. Section 6.2:
>
> Any message received
> prior to an Open message MUST trigger a protocol error condition and
> the PCEP session MUST be terminated.
>
> How? To my understanding no Session context has been created due to
> failure. So it is meant that one should indicate that error and then close
> the TCP connection?

The paragraph has been rewritten. In particular, the last few words.

   Any message received prior to an Open message MUST trigger a protocol
   error condition causing a PCErr message to be sent with Error-Type
   'PCEP session establishment failure' and Error-Value 'reception of an
   invalid Open message or a non Open message' and the PCEP session
   establishment attempt MUST be terminated by closing the TCP
   connection.

> 2. I can't find any information about how messages must be processed in
> relation to each other. There is text on various places talking about
> "pending
> requests" which seem to me to imply that requests can be handled in
> parallel.
> However, that doesn't seem to be explicitly stated. Also the inter message
> type relations in that case should be clarified. Both within a message
> type
> and between the different type of messages.

It seems that the main thing needing clarification here was in regard to a
series of PCE Requests. To that end, Section 6.2 now includes the following
paragraph.

   A PCEP implementation is free to process received requests in any
   order.  For example, the requests may be processed in the order they
   are received, re-ordered and assigned priority according to local
   policy, re-ordered according to the priority encoded in the RP Object
   (Section 7.4.1), or processed in parallel.

> 3. Section 7.3:
>
>  SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
>  identifies the current session.  The SID MUST be incremented each
>  time a new PCEP session is established and is used for logging and
>  troubleshooting purposes.  There is one SID number in each direction.
>
> How do it needs to be incremented? With current formulation any
> incremention, 1, 10 or 100 would be okay.

Section 7.3 now has...

   SID (PCEP session-ID - 8 bits): unsigned PCEP session number that
   identifies the current session.  The SID MUST be incremented each
   time a new PCEP session is established and is used for logging and
   troubleshooting purposes.  Each increment SHOULD have a value of 1
   and may cause a wrap back to zero.

   The SID is used to disambiguate instances of sessions to the same
   peer.  A PCEP implementation could use a single source of SIDs across
   all peers, or one source for each peer.  The former might constrain
   the implementation to only 256 concurrent sessions.  The latter
   potentially requires more states.  There is one SID number in each
   direction.

> Secondly, what happens at wraparound?

This is covered in the new text.

> Based on Lars discuss further clarification may be need if reconnecting or
> multiple simultaneous sessions are allowed.

I think this is covered in the text they added.

> 4. Section 7.4.1:
>
> Once more it is unclear if the request-id-number must be incremented
> with one or larger values are allowed. Also if any specific start value is
> assumed.
>
> Please do also clarify if this value has long term validity and should be
> maintained over multiple PCEP sessions.
>
> Wraparound may also be needed to be specified if the PCEP session
> becomes very long lived, or the space are valid over subsequent sessions

The authors have made some changes to the relevant text, below. I believe
this answers all of your points.

   Request-ID-number (32 bits).  The Request-ID-number value combined
   with the source IP address of the PCC and the PCE address uniquely
   identify the path computation request context.  The Request-ID-number
   is used for disambiguation between pending requests and thus it MUST
   be changed (such as by incrementing it) each time a new request is
   sent to the PCE, and may wrap.

   The value 0x00000000 is considered as invalid.

   If no path computation reply is received from the PCE (e.g. request
   dropped by the PCE because of memory overflow), and the PCC wishes to
   resend its request, the same Request-ID-number MUST be used.  Upon
   receiving a path computation request from a PCC with the same
   Request-ID-number the PCE SHOULD treat the request as a new request
   but an implementation MAY choose to cach path computation replies in
   order to quickly handle restranmission without having to handle twice
   a path computation request should have the first request been dropped
   or lost.  Upon receiving a path computation reply from a PCE with the
   same Request-ID-number the PCC SHOULD silently discard the path
   computation reply.

   Conversely, different Request-ID-number MUST be used for different
   requests sent to a PCE.

   The same Request-ID-number MAY be used for path computation requests
   sent to different PCEs.  The path computation reply is unambiguously
   identified by the IP source address of the replying PCE.

> 5. Section 7.7:
>
>  Bandwidth: 32 bits.  The requested bandwidth is encoded in 32 bits in
>  IEEE floating point format, expressed in bytes per second.  Refer to
>  Section 3.1.2 of [RFC3471] for a table of commonly used values.
>
> Over what time constraints are this value intended to be valid? Due
> to that transmission of packets can be bursty there is need for more
> information. Shouldn't this be a token bucket to better model the
> data moving capability of the request?

We feel that it is important to understand that the reservation being made
is an absolute TE reservation and does not necessarily apply to statistical
measures of traffic. The bandwidth constructs supported by RSVP-TE are
supported by PCEP, but no other forms are supported (as there is no other
in-scope application of PCEP).

To that end, the authors have added just a simple statement to the top of
Section 7.7

   The BANDWIDTH object is used to specify the requested bandwidth for a
   TE LSP.  The notion of bandwidth is similar to the one used for RSVP
   signaling in [RFC2205], [RFC3209] and [RFC3473].

> 6. Section 7.7:
>
> Reference for 32-bit "IEEE floating point format"? Please add it also on
> the
> other places where you use this format in definitions.

Reference added to Section 7.7, 7.8, and 7.16.

> 7. section 7.11:
>
> Please be explicit about which of the documents you use the
> include-any, exclude-any, and include-all. Having browsed through
> RFC 4090 and 3209 I can't find a definition of what "attribute filters"
> are. So please include a reference to the definition of these also.

Added...
   See section 4.7.4 of [RFC3209] for a
   detailed description of the use of resource affinities.

> 8. The SyncTimer:
>
> How can this timer value be local only? The request sender MUST know
> how much time it has to supply all the request before it failing due to
> the
> timer. So if a PCE uses a non default then a failure may occur and the
> PCC doesn't know what value is the one used. This value should either
> be explicit signalled at session opening or at least be included in the
> error
> message.

A note has been added to the description of the SyncTimer in Appendix B.

> 9. Section 7.14, Overload PCE indication.
>
>  Optionally, a TLV named OVERLOADED-DURATION may be included in
>  the NOTIFICATION object that specifies the period of time
>  during whichno further request should be sent to the PCE. Once
>  this period of time has elapsed, the PCE should no longer be
>  considered in congested state.
>
> This design seems to suffer from the same issue as SIP has with its
> overload protection. Especially if I understand it that a PCC to PCE
> request can result in the PCE sending its own request further to the
> next PCE that may be overloaded. In that case it seems that this
> mechanism only can stop the PCC from sending any request, rather
> than the ones that affect a particular upstream PCE.
>
> Secondary, for real safety against PCC->PCE congestion a mandatory
> exponential back-off for requests should be specified. That way a PCE
> that simply stops responding to request will shed load. Seems that with
> TCP this would need to be based on the response time on any request
> and some limitation on how many outstanding request the requestor may
> have.
>
> I am also worried about the lack of mandatory to implement responses
> as this likely will make it hard to determine what will happen in
> real-life
> with multiple implementations making different choices.

You and I discussed this issue by email a bit.

The authors have added some text in this area, but reading through the I-D
we found that most of the cases were already covered.

      *  A PCE implementation SHOULD use a dual threshold mechanism used
         to determine whether it is in a congestion state with regards
         to specific resources monitoring (e.g.  CPU, memory, ...).  The
         use of such thresholds is to avoid oscillations between
         overloaded/non-overloaded state that may result in oscillations
         of request targets by the PCCs.

> 10. Discuss Discuss:
>
> This is in fact a extension on Chris's Discuss regarding the normative
> definition of the formal language used in this document.
> What tools has been used, if any, to determine the validity of the BNF?
> Has the shepherd or AD ensured that that these checks where run on the
> current version?

We discussed this around with Chris, and brought Ross in to help.

I thought we had closed on it with Chris, but it sounds like you may want to 
re-open it. See the other thread on this.

To recap...

The BNF in PCEP is based on (the same as) the BNF used in RSVP and RSVP-TE
(quite a lot of RFCs). It would seem that there is no formal definition, and
the BNF is not even a subset of any formal definition. However, it is not
very complex, and is widely understood by RSVP-TE engineers.

Since PCEP is applicable to the MPLS-TE and GMPLS world, it is appropriate
that it uses the same "unofficial" BNF.

We thought we had agreed that the way to handle this is to include the 
following paragraph...

   The message formats in this document are specified using Backus Naur
   Format (BNF) encoding.  The BNF used is very simple and is modeled on
   that used in the Resource Reservation Protocol (RSVP) [RFC2205], the
   Traffic Engineering extensions to RSVP (RSVP-TE) [RFC3209], and the
   Generalized Multiprotocol Label Switching (GMPLS) extensions to
   RSVP-TE [RFC3473].

I can't say that Chris is happy with this resolution, but he has reduced his 
Discuss to a Comment.

I hope that this addresses all of your points, and you can clear.

Thanks,
Adrian 

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Sep 2008 11:15:38 +0200

Hi,

Please see inline. I have updated my Discuss to reflect the status in 
regards to this version.

>   establishment attempt MUST be terminated by closing the TCP

Okay

>   (Section 7.4.1), or processed in parallel.

Okay, that clearly resolves my discuss item.

> This is covered in the new text.

Fine, with me.

> I think this is covered in the text they added.

Good.

>   but an implementation MAY choose to cach path computation replies in

There seem to be a typo in cache!

>   identified by the IP source address of the replying PCE.

Yes, that answers my questions.

>   signaling in [RFC2205], [RFC3209] and [RFC3473].

Okay, then it is at least clearer what the value is.

[snipped okay resolutions]

>         of request targets by the PCCs.

I am still uncertain if the mechanism provided is sufficient. I am 
afraid the only good way of answering that question would be to do 
simulations. I am not going require that, but I want to state that I 
wouldn't be surprised if additional work would be required in this area. 
The redeeming feature is the PCE is a much more controlled environment 
than SIP.

> I thought we had closed on it with Chris, but it sounds like you may 
> want to re-open it. See the other thread on this.
> 
> To recap...
> 
> I can't say that Chris is happy with this resolution, but he has reduced 
> his Discuss to a Comment.
> 

I will bring this up on tomorrows IESG teleconference and sound out what 
the other ADs think about it.

 From my perspective, I don't see why you couldn't update the BNF usage 
to ABNF (RFC 5234). The requirement on formal language has been clear 
for many years, so I don't see why following established rules is so 
difficult. The learning curve between the language you use and ABNF is 
quite small.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce