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 protected]
https://www.ietf.org/mailman/listinfo/pce
