Hi Joel, Thanks for your useful comments!
I will resolve the comments along with other LC comments after the LC. Pls see inline. Best regards, Mach -------------------------------------------------- From: "Joel M. Halpern" <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2008 3:43 AM To: "Mary Barnes" <[EMAIL PROTECTED]> Cc: <[email protected]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Ross Callon" <[EMAIL PROTECTED]> Subject: Re: [Gen-art] LC review: draft-ietf-ccamp-isis-interas-te-extension-02.txt > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-ccamp-isis-interas-te-extension-02.txt > ISIS Extensions in Support of Inter-AS Multiprotocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) > Traffic Engineering > Reviewer: Joel M. Halpern > Review Date: 7-July-2008 > IETF LC End Date: 14-July-2008 > IESG Telechat date: N / A > > Summary: This document appears ready for publication as a Proposed > Standard. When other document editing is being done, the minor comments > below should be considered. > > Minor Comments: > 1) (comment on abstract based on problem found when reading OSPF > document.) > The last sentence of the Abstract is somewhat confusing. Would it be > accurate to replace > "No support for flooding TE information from outside the AS is > proposed or defined in this document." > with > "No support for flooding information from within one AS to another > AS is proposed or defined in this document." OK, accept. > The reason I ask is that what the document is about is flooding > information about inter-AS links. Such links are actually outside of > the AS, and so the current phrasing is slightly confusing. > As a less informative, but still meaningful last sentence if the > above does not work, would adding the following before the existing > sentence work for you?: > "All information described in this document is originated by the > site AS Border Router (ASBR)." > > 2) It is probably the correct decision to carry the AS number of > neighbors in this mechanism, rather than relying on other protocols > which may or may not have such information. I would suggest adding a > note to the introductory material in section 3 making this point. The > text should simply say something like "while some of this information > may be available within the AS from other protocols, in order to avoid > any dependency on where such protocols are processed, this mechanism > carries all the information needed for the required TE operations." OK, your suggested text will be added into the next revision after LC . > > 3) Is there a reason that the OSPF and ISIS document differ as to the > strength of recommending a specific setting of the flooding scope? The > OSPF documents say that it SHOULD be area specific. The ISIS document > merely describes the two settings (level specific and inter-layer flooding > allowed) without making either one a SHOULD. No, the flooding scope recommended in two drafts is the same, that is the flooding scope could be either area or AS specific, the choice between the use of area and AS flooding scope is a network-wide policy choice. How about we add the following sentence into the section 3.1 before the sentence "The choice between..." of the ISIS draft: "The flooding-scope bit SHOULD be set 0 if the flooding scope is to be limited to within the single IGP area to which the ASBR belongs, or MAY be set to 1 if the information is intended to reach all routers (including area border routers, ASBRs, and PCEs) in the entire ISIS routing domain." > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
