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

[Jonathan Harrison <[e-mail]>]

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]

--- Begin Message ---

Hi Dan and Tina,

Thanks for the comments.

While I agree that there are potentially migration issues when moving MPLS LSPs from IPv4 to IPv6, these are out of scope for the underlying routing protocol - it is an issue for G-MPLS signaling.  In particular, when IPv6 routing information is available in a GMPLS network, this allows the CSPF calculation to provide a route for new IPv6 LSPs.  It is the responsibility of signaling to signal the new LSP and perform refresh and/or make-before-break.

Do you agree that this is out-of-scope for this draft?  If so, would the addition of the following text to the draft be acceptable?

7.  IPv4/IPv6 Migration

The IS-IS extensions described in this document allow the routing of
GMPLS LSPs 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 LSPs
from IPv4 to IPv6 is an issue for GMPLS signaling and is outside the
scope of this document.

Thanks,
Jon


  _____

From: Romascanu, Dan (Dan) [mailto:[e-mail]]
Sent: 06 August 2010 10:39
To: Jonathan Harrison; Jon Berger; Mike Bartlett
Cc: [e-mail]; Tina TSOU
Subject: FW: [OPS-DIR] Operations Directorate Review ofdraft-ietf-isis-ipv6-te-07


Hi,

Please address the issues raised by Tina Tsou in her OPS-DIR review.

Regards,

Dan




  _____

From: [e-mail] [mailto:[e-mail]] On Behalf Of Tina TSOU
Sent: Tuesday, July 06, 2010 4:26 AM
To: [e-mail]
Subject: [OPS-DIR] Operations Directorate Review ofdraft-ietf-isis-ipv6-te-07


Hi,

...

I gave this a read through, it looks like when the original GMPLS-TE extensions were done they did not include IPV6 which was a real oversite and that this draft simply is correcting that mistake. Since all of these TLV's are just parallels of existing TLVs with contents that have V6 as opposed to V4 addresses there are almost certainly no new operational issues with an entirely V6 network.

However that would leave migration as the main concern. Now they don't talk too much about it in this draft so its hard to gauge if they have indeed addressed it properly.

One example would be what happens when a link is identified as V4 at one end and V6 at the other (during a migration to V6 addressing). Does the CSPF and signalling all 'just work'.

What happens to a new PCE and signalling sequence in this case.. more importantly does make before break still work (when the original was V4 signalled)? What about refresh reduction?

I don't know the answers to the above questions since I'd have to go and extensively study the current drafts/RFC's but I think the Authors should add a section on migration and indicate that 1) new LSP setup works, 2) refresh is not affected on existing paths that traverse a link when the V4 is substinted for a V6 with 100'of LSP's up on it and 3) make before break is not affected during migration.

So my general comment would be something like this:

"More information that migration has been taken into consideration and that partial V4/V6 operation works for all the major features of GMPLS/RSVP-TE {make before break, new connections, refresh reduction, FRR etc.} should be added. Or, if this has been addresses somewhere else a comment to that effect with an explicit reference should be added."

B. R.
Tina
http://tinatsou.weebly.com/contact.html

--- End Message ---