Re: [RTG-DIR] RtgDir review: dratf-ietf-isis-ipv6-te-07.txt

[Tomonori TAKEDA <[e-mail]>]

Hi Jon,

Thanks for clarification.
The proposed text is good for me.

Tomonori Takeda

Jonathan Harrison wrote:
> Hi Tomonori Takeda,
> 
> I've made your suggested change to section 2.
> 
> Section 6 is a proposed addition in response to the Operations Directorate review (see the attached e-mail).  As you point out, I should spell out LSP when talking about IS-IS and MPLS to avoid confusion.  The intended meaning was Label Switched Path, so the section should have read as follows.
> 
> 6.  IPv4/IPv6 Migration
> 
>    The IS-IS extensions described in this document allow the routing of
>    GMPLS label switched paths using IPv6 addressing through an IS-IS 
>    network.  There are no migration issues introduced by the addition of
>    this IPv6 TE routing information into an existing IPv4 GMPLS network.
>    Migration of label switched paths from IPv4 to IPv6 is an issue for 
>    GMPLS signaling and is outside the scope of this document.
> 
> Does that seem reasonable?
> 
> Thanks,
> Jon
> 
> -----Original Message-----
> From: Tomonori TAKEDA [mailto:[e-mail]] 
> Sent: 10 August 2010 08:46
> To: Jonathan Harrison
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [RTG-DIR] RtgDir review: dratf-ietf-isis-ipv6-te-07.txt
> 
> Hi Jon,
> 
> Thanks for the update.
> 
> A few more comments (for nits). I think Section 6 (IPv4/IPv6 Migration)
> is added from the version on the IETF site, which is a bit hard to
> understand for me.
> 
> 
> Section 2:
> s/RFC 2119/[RFC2119]
> 
> 
> Section 6:
> Currently,
>    The IS-IS extensions described in this document allow the routing of
>    GMPLS LSPs using IPv6 addressing through an IS-IS network.
> 
> How about,
>   The IS-IS extensions described in this document allow exchanging
>   MPLS/GMPLS TE information in LSPs using IPv6 addressing through an
>   IS-IS network.
> 
> Also, I would suggest to spell out LSP (Link State Protocol Data Unit)
> at its first usage (Section 3.1.1), since some people may think LSP as
> Label Switched Path.
> 
> 
> Section 6:
>    Migration of LSPs from IPv4 to IPv6 is an issue for GMPLS signaling
>    and is outside the scope of this document.
> 
> I am not sure what this means. Are you saying that migration of LSPs
> from IPv4 addressing to IPv6 addressing is a matter of TE database,
> which can be further used to build ERO in MPLS/GMPLS RSVP-TE signaling?
> 
> 
> Thanks,
> Tomonori Takeda
> 
> Jonathan Harrison wrote:
>> Hi,
>>
>> Thanks for the useful comments.  
>>
>> For section 3.1.1, I agree that it is better to consider unique-local (as per RFC 4193) than the deprecated site-local addresses.
>>
>> As for the nits, I'm happy to change the ordering so that section 1 is the overview, which is followed by the requirements words, and I'm happy to add RFC 2119 as a normative reference.
>>
>> I've attached an updated version of the draft with these markups (plus some updated contact details).  Could you please let me know if you think any further changes are required?
>>
>> Thanks,
>> Jon
>>
>>
>> -----Original Message-----
>> From: Tomonori TAKEDA [mailto:[e-mail]] 
>> Sent: 09 August 2010 10:53
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: RtgDir review: dratf-ietf-isis-ipv6-te-07.txt
>>
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review. The purpose
>> of the review is to provide assistance to the Routing ADs. For more
>> information about the Routing Directorate, please see
>> http://www.ietf.org/iesg/directorate/routing.html
>>
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF
>> Last Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>>
>>
>> Document: dratf-ietf-isis-ipv6-te-07.txt
>> Reviewer: Tomonori Takeda
>> Review Date: 9 August 2010
>> IETF LC End Date: Unknown
>> Intended Status: Standards Track
>>
>>
>>
>> Summary:
>> This document is basically ready for publication, but has some minor
>> issues to be considered before publication.
>>
>>
>> Comments:
>> This document is well written and easy to read. I have several nits and
>> one minor question.
>>
>>
>> Major Issues:
>> No major issues found.
>>
>>
>> Minor Issues:
>>
>> Section 3.1.1:
>> Global, site-local and link-local addresses are mentioned. Have you
>> considered that site-local addresses have been deprecated by RFC 3879?
>> Have you considered unique local addresses in RFC 4139?
>>
>>
>> Nits:
>>
>> - I would suggest to add RFC 2119 to normative references.
>>
>> - Usually, the main body starts with Introduction section, followed by
>> Requirement Words. I would suggest that Section 2 (Overview) is moved up
>> to Section 1, followed by Requirement Words (or Requirement Words can be
>> a separate section).
>>
>>
>> Tomonori Takeda
>>
> 
> 


-- 
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: [phone]