Dear Adrian,
Thanks for your comments. Please find response inline. Regards, Dhruv From: [email protected] [mailto:[email protected]] On Behalf Of Adrian Farrel Sent: Friday, March 30, 2012 12:12 AM To: 'JP Vasseur'; [email protected] Subject: 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? [Dhruv Dhody] We will discuss among the co-authors and WG chairs on this. 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. [Dhruv Dhody] We did try to make sure to reuse already defined subobjects but found some gaps which were handled in our document. RFC 4920 defines TLV that can be carried in IF_ID ERROR_SPEC Object to specify the AS and area, but using the TLV as a subobject breaks the definition of IRO Object. 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 [Dhruv Dhody] zhang-pce-hierarchy-extensions provide this information as TLV where we define the information in subobjects format. There is an editor note in the draft in section 3.1.3 stating this. We are working closely with HPCE authors and would make sure to avoid overlaps and redefinations. 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. [Dhruv Dhody] Dully Noted. 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. [Dhruv Dhody] We added a new type in this revision after discussion within the WG (http://www.ietf.org/mail-archive/web/pce/current/msg02580.html) for following reasons - Better application of rules w.r.t domain sequence - define clear order of SubObjects - Different Scope within IRO - Clear Mode of Operations and handling 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). [Dhruv Dhody] We will refine the algorithm and text to make sure above points are considerd. 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. [Dhruv Dhody] We would refine this section to clearly state that both PCE-Sequence and Domain-Sequence can co-exist. But there are some benefits in using domain-sequence esp when such a thing needed to be configured at PCC. I am sure the management considerations can be added within the WG process. [Dhruv Dhody] Dully Noted! Thanks, Adrian From: [email protected] [mailto:[email protected]] On Behalf Of JP Vasseur Sent: 29 March 2012 17:30 To: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
