Re: [Pce] draft-lee-pce-transporting-te-data-01.txt draft-dhodylee-pce-pcep-te-data-extn-01,

[Dhruv Dhody <[e-mail]>]

Hi Sergio,

[Adding WG in CC list]

Thanks for your mail, see inline...

From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]
To: Leeyoung; Dhruv Dhody; Daniele Ceccarelli
Cc: BELOTTI, SERGIO (SERGIO)
Subject: draft-lee-pce-transporting-te-data-01.txt draft-dhodylee-pce-pcep-te-data-extn-01,

Hi Young, Druhv, Daniele

as promised I have some comments/clarifications to send after the meeting in Honolulu.
In general , as I've already said to Young after presentation, I consider the intention to find alternative method to IGP listening to feed TE topology information into PCE a very important issue and the drafts are very useful .
Going into the drafts specifically , about the first draft-lee-pce-transporting-te-data-01.txt  :


1)      In the second architecture option is considered as possible intermediate entity an NMS ? NMS can simple retrieve topology by usual p2p request to nodes.
[Dhruv]: The document does not make any assumption on the intermediate system that implements the pub/sub paradigm; BUT IMHO I don't see intermediate entity as an NMS, I see it more like a special PCE with pub/sub functionality (like RR in case of BGP).

2)      In the third architecture , PCEs to share information among the other PCEs in the domain need to have routing protocol . this does not permit to have a simplified implementation of PCE (since it does not need to "listen" from network nodes no routing instance on board) . Is it correct my feeling?
[Dhruv]: For PCE that share TED information to other PCEs, it can use the same PCEP TED population mechanism that is used by the node (PCC) to PCE. Thus the PCEP extn should be extensible to handle PCE-PCE TED exchange. We do not want the dependence on the routing protocol.


For the draft-dhodylee-pce-pcep-te-data-extn-01 :

*         In 9.2.4 TE Node Descriptor Sub-TLVs is said at the last bullet "There can be at most one instance of each sub-TLV type present in any Node Descriptor". But what does it mean : e.g. if one does not implement  BGP-LS why you would need to put this type of sub-tlv? Or there is a specific value to put in case you don't' use the sub-TLV?

[Dhruv]: The statement means that you should not repeat the same sub-TLV twice. All SUB-TLV are not mandatory, that is, you should include the sub-TLV only if needed; so BGP-LS sub-tlv should be added only if the node implements BGP-LS. I can update text to reflect that.

*         9.2.5 : the chapter report  a table with only specific column for IS-IS , and relative value defined for the sub-tlv. What about if you do not use IS-IS . Moreover the last part  of the paragraph talked about the information present in the LSA/LSP originated by local node, and these information determine the set of sub-TLvs in the link. But what is the relationship with the just above table? Are there other not mentioned sub-TLVs to include? Not totally clear what information is referring to.

[Dhruv]: PCEP will get its own code points, those are in column 1 with TBD; the IS-IS column is to let the reader find the corresponding already-defined-TLV, since we do not want to repeat the format and fields of each of the TLV again in this document. Similar principle is followed by BGP-LS. This does not mean the implementation must have IS-IS enabled to use this extension.

*         9.2.6: Why again a sub-TLV specific for IS-IS ? Moreover even if the draft does not mandate any particular choice of routing protocol, is continuosly referring to BGP-LS , like a translation of BGP-LS sub-TLV into PCEP.

[Dhruv]: see above.

*         9.2.7 : is this TLV optional as for the Node Attributes TLV? If yes this would be explicitly said. In the table the is only mention of values referred to IS-IS or BGP-LS, what about OSPF-TE?
[Dhruv]:We are refereeing to IS-IS and BGP-LS for the TLV format, it has no dependency on the actual protocol. Since the TLV format is the same there is no reason to also mention OSPF here. Following text in the document states this -
The format and semantics of the 'value' fields in most 'Link
   Descriptor' sub-TLVs correspond to the format and semantics of value
   fields in IS-IS Extended IS Reachability sub-TLVs, defined in
   [RFC5305], [RFC5307] and [RFC6119].  Although the encodings for 'Link
   Descriptor' TLVs were originally defined for IS-IS, the TLVs can
   carry data sourced either by IS-IS or OSPF or direct.

We have also updated the extension document, see - http://www.ietf.org/id/draft-dhodylee-pce-pcep-te-data-extn-02.txt

Regards,
Dhruv

Thanks in advance for any clarifications you would provide .

Sergio