[Pce] Adoption of draft-pouyllau-pce-enhanced-errors-03.txt
Dear all, We had a pretty strong support for adopting draft-pouyllau-pce-enhanced-errors a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-pouyllau-pce-enhanced-errors as a PCE WG Document ? Thanks. JP and Julien. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG
Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien.___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG
Yes, support. Huaimo From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, March 29, 2012 12:30 PM To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG
JP team, Yes, I too support. Brgds, Durgaprasad Gangisetti. Sent from my iPhone On Mar 29, 2012, at 12:29 PM, JP Vasseur j...@cisco.com wrote: Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00
Ramon, Thank you for the thorough review and feedback. Please find the consolidated answers from the authors inline below, look for ###. Thank you, Ina -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas Sent: Tuesday, March 27, 2012 7:19 AM To: pce@ietf.org Subject: [Pce] Comments and questions of draft-ietf-pce-stateful-pce-00 [snip] General Comments / Questions === * A first question / comment is whether you plan to focus exclusively on MPLS networks or whether you would also consider including GMPLS in general. In my humble opinion, there is no strong reason to exclude GMPLS, although this may have some implications on the proposed protocol extensions (e.g. notably, the use of the RFC5440 4-byte floating point PCEP BANDWIDTH object could be replaced by e.g. a GENERALIZED_BANDWIDTH, or the fixed-size RSVP-TE ERROR_SPEC). As it is now, it cannot be directly implemented / deployed in e.g our WSON. ### You are right, we do not want to exclude GMPLS, and this was brought up during the last review as well. Addressing different profiles (e.g. MPLS, GMPLS) should be possible within the same framework, and should probably be addressed in separate drafts. * Minor comment: although at the end it is a matter of taste ;-) I am not fond of the naming scheme for your proposed messages. Reporting about LSP state or Updating an LSP is, to some extent, not directly related to Path Computation. For example, your message named Path Computation State Report, that reports the status of an LSP, is confusing IMHO and the prefix Path Computation could be removed. Would you consider a naming scheme more in the lines of, e.g. LSP State Report (LSPRpt) or LSP Update Request (LSPUpd)?. As a side note, it would be slightly less error prone since we have now PCReq / PCRep / PCRpt / PCUpd. In my personal preference, I would only qualify messages with Path Computation if they are actually related to the Path Computation procedure itself (although I admit that it is not always the case, for example, PCNtf messages that do not refer to a given request). ### This is a good suggestion, will update in the next version. State Cleanup --- * I guess you will address state cleanup more deeply in a newer version (in $5.8 you mention state cleanup after session termination) although I am not sure how this coexists with maintaining state between sessions - In short, what would be the suggested procedure? after the (persistent) connection is terminated for some reason, a PCC/PCE is supposed to maintain the state for a given period of time, which is greater than the Delegation Timeout? Also, how do you recognize a given PCC that reconnects after a (persistent) connection was terminated? I am not sure whether some kind of PCC identifier would be needed, since in a given host, several entities may behave as PCCs at different times from the same IP address using ephemeral ports. Recognizing a (Reconnecting) PCC by its IP address may not be a good idea (and for multi-homed hosts, it may change). Do you think a say TLV in the OPEN message or a PCC_REQ_ID as in Monitoring could be necessary to unambiguously identify a PCC? -- I believe that the tuple (PCC_REQ_ID, Session-internal LSPid) may be needed to unambiguously identify an LSP. I would not rely on the IP address of the TCP connection to identify a client. ### Your suggestion for an identifier for the PCC makes sense. State cleanup will be addressed more fully in the next version. Delegation and Revocation - * $5.2.2 When a PCC's PCEP session with the PCE terminates, the PCC SHALL wait a time interval specified in 'Delegation Timeout Interval' and then revoke all LSP delegations to the PCE - I am not sure I understand this part. If the session is terminated, how does the PCC revoke? it just assumes that the PCE is no longer responsible for the LSPs and a PCE will do something similar? In other words, I was confused by the sentence A PCC may revoke this delegation at any point during the lifetime of the PCEP session, yet the timer refers to a procedure that happens after the termination of the connection. If the connection is reestablished before the Delegation Timeout Interval runs out, and sync is skipped, delegations are assumed to stay as they were and the timer is stopped? what if the timer runs out while the PCEP peers are handshaking? don't we risk cases where the actual delegation could be undefined? ### The delegation timeout is for state cleanup on a session failure. The timer should be stopped the moment there is another delegation request on this LSP. We need a better name for this timer too, the current name is confusing. Object ordering * The draft mandates a given object ordering but it does not specify the position of the LSP object within PCReq
Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG
Please accept this comment as an individual comment like all the rest. I have some reservations about adopting this document as a WG draft, but will not register to stand in its way. I understand the motive for this work and, indeed, it fills a hole in the protocol spec. I do hope that the authors are building it for shipping equipment and deployment. If not, would they please consider whether it should be experimental? Here are some comments based on a very light review. I should probably read the document properly some day. I am concerned that this document changes the definition and intent contained in RFC 5440. In my opinion the authors of 5440, and the WG at the time, wen to some lengths to tie the content of objects in PCEP to the same definitions found in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects for path definition, should also pay attention to RFCs 4874 and 4920. The intention is to not define more subobjects than needed and to keep registries aligned. It is also worth noting how 4920 handles 2 and 4 octet AS numbers and that there is overlap in the definition of AS number subobjects with draft-zhang-pce-hierarchy-extensions-01 In this light and on careful reading, the IANA section is somewhat broken and confused about what should be in the registry it is creating. But I am also unsure why a new IRO type is needed. Surely the domain sequence that is used in the computation is also the domain sequence for the path that the LSP will take. This feeds on the points below. The algorithm in 3.4: - assumes only area IDs and AS numbers - assumes that a PCE knows at least one PCE responsible for each of its neighboring domains I would like the authors to take care that the identity of a boundary node does not uniquely identify a next-hop domain (even if it may be successfully used for domain routing given the knowledge of the next domain, next boundary node, or egress node) and the text should not imply that it does. This is hidden at the end of 3.4 some time after the boundary node/link discussion. Shouldn't you allow loose hops in the domain path? (i.e. gaps between domains). Can I also mix other concepts with the domain path? What about a consistent lambda, or a core node that needs to be on the path? In 3.5.7 I don't see that the domain sequence is necessarily an alternative to the PCE sequence. There are cases where even with a domain sequence, a PCE sequence is important. In 3.5.7 you have: All PCE must be aware of all other PCEs in all domain for PCE- Sequence. This is false. Although it is true that a PCE in one domain must be able to route to the IP address of a PCE in a neighboring domain. In 3.5.7 you have: There maybe multiple PCE in a domain, the selection of PCE should not be made at the PCC/PCE(1). This decision is made only at the neighboring PCE which is aware of state of PCEs via notification messages There are four points here: 1. These are unsubstantiated assertions rather than reasons. 2. All neighboring PCEs are sending each other notification messages? 3. PCE choice may be based on capabilities, not just being up 4. In HPCE, it is quite reasonable for the parent to select the children Section 5 will need loads of work because the domain sequence (even for inclusion, not reporting) provides information valuable to an attacker. I am sure the management considerations can be added within the WG process. Thanks, Adrian From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP Vasseur Sent: 29 March 2012 17:30 To: pce@ietf.org Subject: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new PCE WG Dear all, We had a pretty strong support for adopting draft-dhody-pce-pcep-domain-sequence-02 a PCE Working Group during our PCE WG meeting but as usual we'd like to confirm on the mailing list. Could you please let us know if you are in favor/opposed to adopting draft-dhody-pce-pcep-domain-sequence-02 as a PCE WG Document ? Thanks. JP and Julien. ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
