[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt
Hello,
Below are some comments on section "4.1.1 MPLS Backbone".
First paragraph:
================
- I think we should be talking about offering "IPv6 connectivity via transport of IPv6 over MPLS" as opposed to offering "IPv6-over-MPLS connectivity".
- In addition to softwrae upgrade, I think it is worth conveying that support of IPv6 MPLS in the core would involve complete control plane upgrade including IPv6 routing if it is not there, configuration of IPv6 label distribution, monitoring, operations, ...
So, I would suggest enhancing enhancing 1st paragraph to:
"If MPLS is already deployed in the backbone, it may be desirable to provide IPv6 connectivity via transport of IPv6 over MPLS. However, setting up an IPv6 Label Switched Path (LSP) requires support of the corresponding control plane (routing, signaling) in the MPLS network; both LDP and RSVP-TE can set up IPv6 LSPs, but this would require corresponding upgrade (software, configuration, operations) in the MPLS core network. "
Second paragraph:
=================
I suggest replacing "may be economically attractive" by "may be attractive".
This will make sure we have consistent terminology with previous sentences (eg "approaches 1 and 2 are the most attractive") and avoid confusion (eg what is "economically attractive" but inattractive from other perspectives?).
Last paragraph
==============
I have a number of problems with that paragraph as it is worded:
- "recommeding ... might not be such a good idea": I don't find this a very precise recommendation.
- "No particular reason exists to avoid adding IPv6". Shouldn't we leave it to operators to decide for themselves whether avoiding/postponing complete upgrade of the control plane of their core (which may already be carrying L3VPN, L2VPN, Voice Trunking...) is a valid reason or not? The previous paragraph attempts to provide a balanced description of the pros and cons of each approach. It says "Approach 4 may be attractive for an operator who does not wish to upgrade the MPLS network and has a large-scale deployment." I think this is a more accurate statement.
- "Software upgrades are commonplace in MPLS networks". Is this suggesting that upgrades are more commonplace in MPLS networks than IP networks offering enterprise services? Isn't there a distinction to be made between upgrade on the edge when new services are added, and upgrade to the core which is more and more "service-unaware" ?
But I see two valid points in the paragraph:
- [BGPTUNNEL] is primarily designed for migration period from existing environments, as opposed to the grand scheme of things for the long term future where IPv6 will be everywhere
- where installed equipment has higher MPLS forwarding performance than native IPv6 performance, carrying IPv6 over MPLS results in performance benefits.
My recommendation is to drop the last paragraph and capture these two points by extending the last sentence of the second paragraph into:
"Approach 4 may be attractive for an operator who does not wish to upgrade the MPLS core network at this stage and/or who wants to take advantage of higher MPLS forwarding performance on installed equipment, and has a large-scale deployment. "
Thanks
Francois
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
>> Sent: vendredi 6 février 2004 06:59
>> To: v6ops@ops.ietf.org
>> Cc: jonne.soininen@nokia.com; mikael.lind@teliasonera.com
>> Subject: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt
>>
>>
>> Hi all,
>>
>> This is a WG Last Call for comments on sending
>> draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and
>> Analysis for Introducing IPv6 into ISP Networks" to the IESG for
>> consideration as BCP:
>>
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-01.txt
Please review these documents carefully, and send your feedback to the
list. Please also indicate whether or not you believe that this document
is ready to go to the IESG.
There has been a lack of extensive reviews from the start, so
reviewing this document would be especially welcome.
The last call will end in about 2.5 weeks, on 24th February.
Pekka & Jonne