Hi, Xian, PCEers > > I did not see any reply on my previous comments I repost them with > separate threads, as the initial one were big > 1. Section 2.2.1 : this is not only useful for stateful, but also > for stateless, this should be integrated to draft-ietf-pce-inter-layer- > ext > [Xian]: point taken. the authors of draft-ietf-pce-inter-layer-ext has > agreed to put in that draft and we only cite it in this draft. > > 2. Section 2.3 : is this GMPLS specific or stateful specific? > [Xian]: It is GMPLS specific (please see the updated version).
I was referring to the paragraph about LSP state synchronization and multi-domain networks. The multi-domain aspect is not GMPLS specific, it should be addressed IMHO in the framework/extension part. > > 3. Section 2.4 : IMHO this should not be necessary, the generic > part should describe how to deal with non-supported objects, > [Xian]: Sorry, i do not follow your quesiton here. This section is > GMPLS specific and it does not describe how to deal with non-supported > object. If the generic part was simply accepting the PCEP <path> protocol grammar (Which you are re-defining here) and how to deal with non-supported objects (Similar to RFC5440)this would not be needed. More specifically I think there is actually few things to add: - <path> is already described in RFC5440 and extensions, do you intend to redefine this also for PCREp? - GENERALIZED-ENDPOINTS is covered by the MPLS-TE (as the ENDPOINTS object is supported) - PROTECTION_ATTRIBUTE TLV is also covered by the MPLS-TE (LSPA object is supported) - ERROR_SPEC : would'nt it be better and future proof to define one TLV containing any RSVP ERROR SPEC object, similar to the ERO > > 4. Section 2.5 : This seems generic, I would expect a new section > in the WG document describing this generic procedure, it does not match > the scope of this document., > [Xian]: We are focusing on the technical points to support stateful PCE > usage in GMPLS networks, it may work for MPLS-TE as well. If agreed, I > have no issue moving this to where they are agreed to be. It would be interesting to hear from other document editors here. > > 5. Section 2.6 : how is this GMPLS-specific? This should be > another set of extensions maybe. > [Xian]: Indeed, they deserve a separate draft so we did that. > > My understanding is that the required extension to support an *active* > stateful PCE for GMPLS network is contained in section 2.4, which > indicates the following: > > o GENERALIZED BANDWIDTH -> Object, optional in the GMPLS extensions > BTW > o PROTECTION ATTRIBUTE -> this should be LSPA PROTECTION-ATTRIBUTE > TLV --> This is already supported by draft-crabbe-pce-stateful-pce- > mpls-te-00 > o Extended Objects to support the inclusion of label sub-object > - RP > - IRO > - XRO > --> Those are not specific to GMPLS > > So the only missing object to support active stateful GMPLS PCE is an > optional GENERALIZED-BANDWIDTH, this does not seem a big requirement. > I would rather see one solution for passive stateful and one for active > stateful than a mix of passive and active, plus 3 similar RSVP-TE > solutions. > > [Xian]: This draft intends to show the necessity to cover GMPLS in > stateful PCEP extensions, since we believe draft-ietf-pce-gmpls-pcep- > extensions cannot cover that (due to the introduction of path update > and path report functions, please see our update for the details). As > for how the PCEP extension draft(s) should be organized, I am pretty > flexible and open to suggestions, :-). ;-) > > Mit freundlichen Grüßen / Best Regards > Cyril Margaria > > Nokia Siemens Networks Optical GmbH > St.Martin-Str. 76 > D-81541 München > Germany > mailto:[email protected] > Phone: +49-89-5159-16934 > Fax: +49-89-5159-44-16934 > ---------------------------------------------------------------- > Nokia Siemens Networks Optical GmbH > Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz > Sitz der Gesellschaft: München / Registered office: Munich > Registergericht: München / Commercial registry: Munich, HRB 197143 > > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
