|
Hi Ignas, our apologies for the delayed response. Please find attached revision 10 of draft-ietf-teas-lsp-diversity, which has not been submitted yet. All changes compared to revision 08 are still visible. Revision 09 has been submitted during IETF100 with some IESG review comments incorporated. Please find our replies to your comments below. Could you please let us know whether your comments are adequately addressed. Thanks, Dieter and co-authors On 30.08.2017 11:23, Ignas Bagdonas
wrote:
Reviewer: Ignas Bagdonas Review result: Has Issues Hi there. I have reviewed this document as part of the Operations Directorate's document review process. Overall the document seems to be heading in the right direction. There are some issues related to clarity of RFC2119 language usage, especially less restrictive forms and how that would relate to interoperability, the handling of undefined values and errors, terminology could be aligned better to base GMPLS and TE specifications. see attached draft revision 10 The document does not cover manageability or operational considerations at all - given that it is proposing protocol extensions that require operator involvement, a section on operational considerations and possible extensions to management models and procedures should be covered. The Path-Key based signalling form seems to have interdomain signalling related security aspects that would need to be looked a bit deeper. We do not believe that neither the Path Key nor the PAS are forming a security issue at domain boundaries as they are abstract identifiers that do not allow an another domain to infer anything about the domain topology (link utilization for example) or the failure situation in the domain. Security considerations have been taken into account when the solutions have been developed. The document would benefit from terminology and acronyms section specific to the proposed mechanism. see attached draft revision 10 The larger comment on time scale and granularity aspects of SRLG aware path calculation. The document is based on the assumption of a longer time period between LSP signalling requests and path reoptimizations. What is the reason for it, and what would be needed if the proposed solution is expected to operate in closer to real time environment (minutes instead of weeks)? What is the source of the time granularity restriction? see attached draft revision 10 - the only timing requirement for the solution is that the LSPs are established sequentially as opposed to simultaneously. Diversity information flooding specifics are stated as being out of scope. How would that impact interoperability? This I-D defines RSVP signaling extensions and routing information exchange is therefore out of scope. PAS identifier name space may be smaller or not comparable with SRLG group identifier name space, is there a need to have any form of mapping mechanism in place? The PAS is an abstraction of SRLG information and the smaller name space is therefore not an issue. Small nits: - Example based on figure 1 has got details wrong. - Terms need to be consistent throughout the document - initiated/controlled is used interchangeably, this seems to be coming from the merge of the 3 original drafts. - There is no "IPv4/IPv6" diversity identifier, they are separate per address family and text should be expanded to describe them separately. - Could the text describing the operation of L bit be simplified by stating that L bit has the same semantics as in any other object - strict/loose hop selection, and therefore diversity identifier is interpreted as a strict or loose entity that MUST or MAY be taken into account? see attached draft revision 10 There is a set of editorial nits and fixes throughout the document, a marked version of the document is attached. Thanks for the detailed review of draft-ietf-teas-lsp-diversity-08! Please find attached the document with your comments and our replies (draft-ietf-teas-lsp-diversity-08-comments-ibagdona-170829-final). |
Attachment:
draft-ietf-teas-lsp-diversity-08-comments-ibagdona-170829-final.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Attachment:
draft-ietf-teas-lsp-diversity-10.doc
Description: MS-Word document