[Pce] New Liaison Statement, "LS on ITU-T SG15 OTNT standardization work plan to pce"
Title: LS on ITU-T SG15 OTNT standardization work plan to pce Submission Date: 2014-12-19 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1368/ Please reply by 2015-06-07 From: ITU-T SG 15 (Greg Jones ) To: Path Computation Element (JP Vasseur , Julien Meuric ) Cc: Adrian Farrel ,Alia Atlas ,pce@ietf.org,John Drake ,Scott Mansfield Response Contact: naotaka.mor...@ntt-at.co.jp Technical Contact: Purpose: For comment Body: Thank you for your previous review and comments on “Optical Transport Networks & Technologies standardization work plan.” Attached is Issue 19, the latest version that was updated by the SG15 meeting in December 2014. We appreciate your continued review and comments which allow us to keep the document up-to-date. Attach: − OTNT standardization work plan, Issue 19 (TD282/PLEN Rev.1) Attachments: LS on ITU-T SG15 OTNT standardization work plan to pce https://datatracker.ietf.org/documents/LIAISON/liaison-2014-12-19-itu-t-sg-15-pce-ls-on-itu-t-sg15-otnt-standardization-work-plan-to-pce-attachment-1.zip ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01
El 01/12/2014 a las 18:18, julien.meu...@orange.com escribió:
Dear all,
As planned, this message ignites a 3-week WG Last Call on both
draft-ietf-pce-pce-initiated-lsp-02
Hi authors, all,
A fast review of the draft, please note:
* Error: "To indicate a delete operation, the PCE MUST use the R flag
in the
SRP object in a PCUpd message. As a result of the deletion request,
the PCC MUST remove all state related to the LSP, and send a PCRpt
with the R flag set in the LSP object for the removed state"
it should be PCInitiate, as later described in Section 5.4
"PCE-initiated removal of a PCE-initiated LSP is done by setting the R
(remove) flag in the SRP Object in the PCInitiate message from the
PCE." as well as the RBNF (note that, personally I would favor being
picky as in "in the SRP object of the PCE-initiated-lsp-instantiation
within the PCInitiate message" etc. notably when multiple lsp requests
can be in a message)
* Confused by the sentence " Every request from the PCE receives a new
SRP-ID-number. This number is unique per PCEP session and is
incremented each time an operation
(initiation, update, etc) is requested from the PCE" i.e., the
"unicity-per-session" (although the intent is clear)
* Indent 0,1,2,3 digits to describe bit position in the SRP object format.
* Minor nit: IANA considerations section should mention new R flag in SRP.
* Error-value=13: LSP cleanup TLV missing -> this looks like a leftover
from an old version?
* I would have some very minor comments about error conditions,
hopefully triggering some discussion
- I am a bit confused about the differences between ET=19 -Invalid
operation- and ET=24 -LSP instantiation error-
("Is the error a result of an invalid operation? ;)"
- Why is "non-zero plsp-id" an invalid operation rather than a "bad
parameter value"?
- Why is "Speaker identity included for an LSP that is not
PCE-initiated" a bad parameter rather than an invalid operation?
- Why is there a type "bad parameter value" yet the error "unacceptable
instantiation parameters" a value within the "instantiation error" type?
I am aware there may be deployments and changing this may be problematic,
Best regards
Ramon
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
[Pce] Fwd: RFC 7413 on TCP Fast Open
FYI: an experimental RFC. Message transféré Date : Thu, 18 Dec 2014 16:42:57 -0800 De : rfc-edi...@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7413 Title: TCP Fast Open Author: Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Status: Experimental Stream: IETF Date: December 2014 Mailbox:ych...@google.com, hk...@google.com, sivasan...@cs.ucsd.edu, arv...@google.com Pages: 26 Characters: 59945 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-fastopen-10.txt URL:https://www.rfc-editor.org/rfc/rfc7413.txt This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
