Hi, Please see inline. I have updated my Discuss to reflect the status in regards to this version.
Adrian Farrel skrev: > 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. Okay > >> 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. Okay, that clearly resolves my discuss item. > >> 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. > Fine, with me. >> 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. > Good. >> 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 There seem to be a typo in cache! > 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. > Yes, that answers my questions. >> 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]. > Okay, then it is at least clearer what the value is. [snipped okay resolutions] >> 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. > 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. >> 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 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 PROTECTED] ---------------------------------------------------------------------- _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
