Re: [mpls] LDP IPv6

"Bin Mo (bmo)" <bmo@cisco.com> Thu, 12 August 2010 15:42 UTC

Return-Path: <bmo@cisco.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 C90243A67FB for <mpls@core3.amsl.com>; Thu, 12 Aug 2010 08:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.561
X-Spam-Level:
X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 imX3D4ynOaqn for <mpls@core3.amsl.com>; Thu, 12 Aug 2010 08:42:54 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C5DAD3A6407 for <mpls@ietf.org>; Thu, 12 Aug 2010 08:42:53 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJ+zY0ytJV2c/2dsb2JhbACgPnGhPptQhToEhC6IDQ
X-IronPort-AV: E=Sophos;i="4.55,358,1278288000"; d="scan'208";a="146946933"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2010 15:43:30 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o7CFhUN7007990; Thu, 12 Aug 2010 15:43:30 GMT
Received: from xmb-rcd-102.cisco.com ([72.163.62.144]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Aug 2010 10:43:30 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Aug 2010 10:43:28 -0500
Message-ID: <1ED479097DCF154A89226065E522D5A80273C4A3@XMB-RCD-102.cisco.com>
In-Reply-To: <AANLkTinBt0U_oK4xSUMFcDG_xbMYS4JjC17jEquzuRWK@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls] LDP IPv6
Thread-Index: Acs52CrK6ktvmmAyQmi3Z7/O2N/FPgAWvHJQ
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> <AANLkTinBt0U_oK4xSUMFcDG_xbMYS4JjC17jEquzuRWK@mail.gmail.com>
From: "Bin Mo (bmo)" <bmo@cisco.com>
To: Vishwas Manral <vishwas.ietf@gmail.com>
X-OriginalArrivalTime: 12 Aug 2010 15:43:30.0142 (UTC) FILETIME=[1CD267E0:01CB3A35]
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 15:42:55 -0000

Hi Vishwas,

Thanks for your response. Please see my follow-up inline.

> 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.
[bmo] OK. The current text doesn't make this requirement clear (at least to me).
> 
> > 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.
[bmo]
Sounds good. There may be situations, however, where the session will not
be easy to establish.
RFC5036 says in session setup, one LSR plays passive role and the other plays
active role. For example, If based on the address, one LSR should play passive
role in IPv4 TCP connection and it aborts IPv6 TCP connection setup, the other
LSR should play passive role in IPv6 TCP connection and it aborts IPv4 TCP
connection setup, then they will have to re-try. Timing involves in such situation
but could happen.
[bmo]

Thanks

/Bin

> 
> 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
> >