[OSPF] Fwd: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt

Acee Lindem <acee.lindem@ericsson.com> Thu, 17 April 2014 21:12 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39101A011C for <ospf@ietfa.amsl.com>; Thu, 17 Apr 2014 14:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S5vgNaCGpRC for <ospf@ietfa.amsl.com>; Thu, 17 Apr 2014 14:12:14 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 51B121A0054 for <ospf@ietf.org>; Thu, 17 Apr 2014 14:12:14 -0700 (PDT)
X-AuditID: c618062d-f79f66d000001393-13-534ff538003c
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BF.CC.05011.835FF435; Thu, 17 Apr 2014 17:37:28 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Thu, 17 Apr 2014 17:12:10 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: OSPF List <ospf@ietf.org>
Thread-Topic: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt
Thread-Index: AQHPWWKkr2iEvctPGUWHpQX02ko1EQ==
Date: Thu, 17 Apr 2014 21:12:09 +0000
Message-ID: <01BA9225-3C0E-4830-BE03-FBEFE51CC2D1@ericsson.com>
References: <534E61F0.4040105@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_01BA92253C0E4830BE03FBEFE51CC2D1ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPoK7FV/9gg/a3qhYt9+6xOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/O708wFG/0rXm4/ydbAeNali5GTQ0LARGLZpTtMELaYxIV7 69m6GLk4hASOMkq8+dIM5SxnlOj+N4MdpIpNQEfi+aN/zCC2iICsxNIl+1lBbGGBEInOb/MY IeIhEi3Nz1kgbD2JA2uPgdWzCKhKbNqyBMzmFbCXePKiHWgBB9ACDYl9ezRAwoxAR3w/tQbs IGYBcYlbT+ZDHScgsWTPeWYIW1Ti5eN/rBC2ksSc19eYIeqTJea+XM4EMV5Q4uTMJywTGIVn IRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4DNVrLXHz8g0WZDULGDlWMXKUFqeW5aYb GWxiBEbKMQk23R2Me15aHmIU4GBU4uGdct03WIg1say4MvcQozQHi5I475e3zkFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGBeWcB27NWHNy5Usa8+liWszHN3c4xtz4lMq79c1B16c+zl5 xs27QgwRET8Cv3ys+78id+Vme5m98/4mfjF6Lfdy39Lc1O2lNsX39s/7uLdvgny5VIX7rbOP D4Y5BhizOWgzuH9YWSv2xrztslND9LKpc+02v05+Yb/XZpqVqGKt29Qn9gZN1UeUWIozEg21 mIuKEwHZaapAdQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/LYRF2hepmCe4RIx7hyG0HPMTTWE
Subject: [OSPF] Fwd: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 21:12:18 -0000

All,

The gist of the draft is to allow a single OSPF(v3) instance to signal LSP endpoints for both IPv4 and IPv6 and, thus, consolidate the TE routing domain. Is there interest in considering this work?

I would support it since it seems fairly straightforward (unless my reading has missed something).

Thanks,
Acee

Begin forwarded message:

From: Anton Smirnov <asmirnov@cisco.com<mailto:asmirnov@cisco.com>>
Subject: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt
Date: April 16, 2014 at 6:56:48 AM EDT
To: OSPF List <ospf@ietf.org<mailto:ospf@ietf.org>>

  Hello,
  authors of this draft would like to solicit feedback. This draft was presented to WG in London and draft was updated couple of days ago to rectify notes received after the presentation.
  The draft proposes technique how IPv6 routes should be calculated over MPLS TE signaled by OSPFv2.

  The draft discusses why simple solution to the problem not requiring standardization works most of the time but if it fails it may fail with very big impact to the network and thus unacceptable. But presentation delivered during the meeting discussed this in pictures and in greater length, so if after reading the draft you would still not be convinced simple solution is not good enough I encourage you to review slide deck presented during the meeting.

Anton Smirnov



-------- Original Message --------
Subject: New Version Notification for draft-smirnov-ospf-xaf-te-01.txt
Date: Mon, 14 Apr 2014 13:48:01 -0700
From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>


A new version of I-D, draft-smirnov-ospf-xaf-te-01.txt
has been successfully submitted by Anton Smirnov and posted to the
IETF repository.

Name: draft-smirnov-ospf-xaf-te
Revision: 01
Title: OSPF Routing with Cross-Address Family MPLS Traffic Engineering Tunnels
Document date: 2014-04-14
Group: Individual Submission
Pages: 7
URL: http://www.ietf.org/internet-drafts/draft-smirnov-ospf-xaf-te-01.txt
Status:         https://datatracker.ietf.org/doc/draft-smirnov-ospf-xaf-te/
Htmlized:       http://tools.ietf.org/html/draft-smirnov-ospf-xaf-te-01
Diff: http://www.ietf.org/rfcdiff?url2=draft-smirnov-ospf-xaf-te-01

Abstract:
  When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network
  the Multiprotocol Label Switching (MPLS) TE Label Switched Paths
  (LSP) infrastructure may be duplicated, even if the destination IPv4
  and IPv6 addresses belong to the same remote router.  In order to
  achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be
  computed over MPLS TE tunnels created using information propagated in
  another OSPF instance.  This is solved by advertising cross-address
  family (X-AF) OSPF TE information.

  This document describes an update to RFC5786 that allows for the easy
  identification of a router's local X-AF IP addresses.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat



_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf