Re: [mpls] LDP IPv6

Vishwas Manral <vishwas.ietf@gmail.com> Thu, 12 August 2010 04:37 UTC

Return-Path: <vishwas.ietf@gmail.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981B73A684A for <mpls@core3.amsl.com>; Wed, 11 Aug 2010 21:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtxafpYkwU+X for <mpls@core3.amsl.com>; Wed, 11 Aug 2010 21:37:32 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 43B553A6861 for <mpls@ietf.org>; Wed, 11 Aug 2010 21:37:32 -0700 (PDT)
Received: by qyk29 with SMTP id 29so1024378qyk.10 for <mpls@ietf.org>; Wed, 11 Aug 2010 21:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cuUOS61TiNh8Qn47HnIzNgD7jmKuHst/FkR9Za5rq1s=; b=AH0zyuPbXhuMCQNys/N0VyGOxdqA+dBDGM5sVQuGTMnfMX1QhhS/qtNZR4V0GhktC9 uCvsId1nANzmLH8WUnngnq5OpMwSDQdkB8eUIyF1FCFN1M155+Z5zqILMKbiUPXEXU53 6RaqkhQ6moVJJNnBgpCzc5JjdxGzdnPWhoqgc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=APlraMhf/fE5nQoCOna924XBRtaRF+inTVlIaOm8SrU5sS0+k2K+qn8ERILZ1bmXG9 ayEHTPekV8iFAVeSDpDYFeztGrdF2zeZzOjJP6x5oGQWnTQXTsSuhZjI2lF1o9V0LMpg N5OS83LzZRQd6KXWUaVK7gHk8ShZLvYgW9QnQ=
MIME-Version: 1.0
Received: by 10.229.228.146 with SMTP id je18mr10544034qcb.13.1281587888578; Wed, 11 Aug 2010 21:38:08 -0700 (PDT)
Received: by 10.229.109.207 with HTTP; Wed, 11 Aug 2010 21:38:08 -0700 (PDT)
In-Reply-To: <1ED479097DCF154A89226065E522D5A8026763B9@XMB-RCD-102.cisco.com>
References: <h2g77ead0ec1004061223k7cc69585ncf8761efb0df2d33@mail.gmail.com> <4395962A7C18D84191B205AD7089698305CA00CA@S4DE9JSAAIB.ost.t-com.de> <r2h77ead0ec1004120755za2c9aadcw9184a1d56cd10c5b@mail.gmail.com> <q2s77ead0ec1004120940r875bc282y7edd293bd846c57@mail.gmail.com> <1E2FA684-E5E0-45FA-9885-0BA7C288AC08@eng.gxn.net> <alpine.DEB.1.10.1004150758320.6768@uplift.swm.pp.se> <x2k77ead0ec1004150817v5f2da373lce60f3827a5e00d7@mail.gmail.com> <o2r3c502ff41004160103qf32c87dbn9c9cfd67f057631a@mail.gmail.com> <v2s77ead0ec1004160659r93f30297k8e6f262bf9465a13@mail.gmail.com> <AANLkTinAGcPj2DUH8iUs0QxZTxoU9ikPdbwRq_Z1Pz7x@mail.gmail.com> <1ED479097DCF154A89226065E522D5A8026763B9@XMB-RCD-102.cisco.com>
Date: Wed, 11 Aug 2010 21:38:08 -0700
Message-ID: <AANLkTinBt0U_oK4xSUMFcDG_xbMYS4JjC17jEquzuRWK@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: "Bin Mo (bmo)" <bmo@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: mpls@ietf.org
Subject: Re: [mpls] LDP IPv6
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2010 04:37:33 -0000

Hi Bin,

Thanks for the thoughtful points you have brought up.
> I have couple of questions on draft-manral-mpls-ldp-ipv6-03.
>
> 1. In section 3 LSP mapping, is IPv4 hello adjacency on an interface required to forward labeled IPv4 traffic to nexthop, and IPv6 hello adjacency required to forward labeled IPv6 traffic?

VM> Yes.

> 2. In section 6.1 transport connection establishment, if both IPv4 and IPv6 transport addresses are available, any preference which transport address should be preferred?
VM> The preference can be local and is based on which transport
session is established first.

Do let me know if this answers your questions?

Thanks,
Vishwas

> Thanks
>
> /Bin
>
>> -----Original Message-----
>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
>> Vishwas Manral
>> Sent: Monday, July 26, 2010 5:39 PM
>> To: George Swallow (swallow); Loa Andersson
>> Cc: Rob Shakir; mpls@ietf.org; faz@netfm.co.uk
>> Subject: [mpls] LDP IPv6
>>
>> Hi Chairs,
>>
>> We would like to request you to have a WG call to gauge support and
>> adopt the document LDP IPv6 as a working Group item.
>>
>> The document is located at
>> http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-03
>>
>> The document in the past has got some review on the list.
>>
>> Thanks,
>> Vishwas
>>
>> On Fri, Apr 16, 2010 at 6:59 AM, Vishwas Manral
>> <vishwas.ietf@gmail.com> wrote:
>> > Hi Egor,
>> >
>> > 1. As Mikael brought out the question of what else is missing I
>> > brought up the MIB and RSVP-TE issues. I will bring the details out
>> in
>> > another mail with the correct subject line.
>> > 2. I guess now that we have more knowledge of the draft we can
>> > actually try to push it further.
>> >
>> > Thanks,
>> > Vishwas
>> >
>> > On Fri, Apr 16, 2010 at 1:03 AM, Egor Zimin <lesnix@gmail.com> wrote:
>> >> Hi, Vishwas,
>> >>
>> >> 1. About RSVP-TE and IPv6 Router Alert option.
>> >> I do not quite understand your opinion.
>> >> Do you propose to remove Router Alert option for IPv6 ? Why ?
>> Because of
>> >> lack of RSVP-TE IPv6 implementations alone ? Because of only RSVP TE
>> uses
>> >> this option ? Also, what security issues do you mean ?
>> >> And... what does that have to LDPv6 draft discussion?
>> >>
>> >> 2. About draft-manral-mpls-ldp-ipv6-03:
>> >> I think, the changes and clarifications proposed in the draft are
>> very
>> >> obvious and not so significant. In fact, the draft only clarifies
>> peer
>> >> discovery and transport session establishment procedures for IPv6. I
>> don't
>> >> understand why this draft has not yet become RFC.
>> >>
>> >> 2010/4/15 Vishwas Manral <vishwas.ietf@gmail.com>
>> >>>
>> >>> Hi Mikael/ Rob/ Farhan/ Egor,
>> >>>
>> >>> > Considering IPv4 runout I definitely see greenfield rollout in 1-
>> 2
>> >>> > years wanting to do this IPv6 only, and considering code usually
>> >>> > takes time to be finished the standards should definitely be done
>> >>> > by now.
>> >>> >
>> >>> > What else is missing?
>> >>> Let me begin by saying that most drafts/ RFC's have some IPv6
>> >>> component to them. This however is appended as an add-on in some
>> >>> cases. As most of these have not been looked at in detail there are
>> >>> some holes in the RFC for IPv6.
>> >>>
>> >>> I found similar holes a couple of years back and wrote this and the
>> >>> MPLS-TC IPv6 MIB draft. I also noticed that for RSVP-TE for IPv6 we
>> do
>> >>> not have support for Router Alert in a lot of platforms. It also
>> has
>> >>> all the security issues aside from that.
>> >>>
>> >>> As RSVP-TE seems to be carrying Router Alert as a legacy thing and
>> as
>> >>> RSVP-TE IPv6 is not implemented on the field I think it would be
>> good
>> >>> to do away, remove the use of Router Alert in RSVP for IPv6.
>> >>>
>> >>> What do folks on the list think?
>> >>>
>> >>> BTW, I had mails from a couple of more operators in private and
>> have
>> >>> forwarded them to the chairs.
>> >>>
>> >>> Thanks,
>> >>> Vishwas
>> >>>
>> >>> On Wed, Apr 14, 2010 at 11:01 PM, Mikael Abrahamsson
>> <swmike@swm.pp.se>
>> >>> wrote:
>> >>> > On Wed, 14 Apr 2010, Rob Shakir wrote:
>> >>> >
>> >>> >> I'd just like to speak up in support of this draft also. As an
>> operator
>> >>> >> that is progressing an IPv6 rollout, we are finding that in a
>> number of
>> >>> >> places, the only need to utilise 6PE is in order to address the
>> lack of
>> >>> >> support for IPv6 in LDP.
>> >>> >
>> >>> > +1 from me as well, I'm actually surprised that there hasn't been
>> more
>> >>> > work
>> >>> > in establishing feature parity between IPv4 and IPv6 in the
>> control
>> >>> > plane.
>> >>> > I'd imagine that by now it would be possible to implement
>> >>> > standards-based
>> >>> > IPv6 only control plane with equal functionality as is today
>> possible
>> >>> > with
>> >>> > IPv4.
>> >>> >
>> >>> >> Whilst I think it's unlikely that many operators are currently
>> putting
>> >>> >> this down as a mandatory requirement, it's definitely something
>> that I
>> >>> >> believe is required.
>> >>> >
>> >>> > Considering IPv4 runout I definitely see greenfield rollout in 1-
>> 2 years
>> >>> > wanting to do this IPv6 only, and considering code usually takes
>> time to
>> >>> > be
>> >>> > finished the standards should definitely be done by now.
>> >>> >
>> >>> > What else is missing?
>> >>> >
>> >>> > --
>> >>> > Mikael Abrahamsson    email: swmike@swm.pp.se
>> >>> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Egor Zimin
>> >>
>> >
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>