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

Acee Lindem <acee.lindem@ericsson.com> Thu, 17 April 2014 21:08 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 591A21A0119 for <ospf@ietfa.amsl.com>; Thu, 17 Apr 2014 14:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O8zLMPJ1XFFM for <ospf@ietfa.amsl.com>; Thu, 17 Apr 2014 14:08:38 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB181A0054 for <ospf@ietf.org>; Thu, 17 Apr 2014 14:08:38 -0700 (PDT)
X-AuditID: c618062d-f79f66d000001393-7e-534ff45f0c04
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 48.AC.05011.F54FF435; Thu, 17 Apr 2014 17:33:51 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 17 Apr 2014 17:08:32 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Anton Smirnov <asmirnov@cisco.com>
Thread-Topic: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt
Thread-Index: AQHPWWKkr2iEvctPGUWHpQX02ko1EZsWkqeA
Date: Thu, 17 Apr 2014 21:08:32 +0000
Message-ID: <9DEEF3C3-BAAB-4019-82B9-82F5C392A691@ericsson.com>
References: <20140414204801.6069.46438.idtracker@ietfa.amsl.com> <534E61F0.4040105@cisco.com>
In-Reply-To: <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.11]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <345166D1692BE745BFB8AE582663DFF3@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPn278F/9gg/NT1S1atrFatNy7x+7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZRy99Yul4L5kxeFXNxgbGD+IdDFyckgImEi0 v3vDDGGLSVy4t56ti5GLQ0jgKKPE7p2PmSCc5YwSPReegVWxCehIPH/0D8wWEVCT2Hz3EyuI zSwgK/FsWxNYXFggWGLmmfesEDUhEi3Nz1m6GDmAbCOJKYvrQcIsAqoSc19MZQexeQXsJaa8 +QXWKiQQL3Fu3XIWEJtTQFPi4v6tYDWMQMd9P7WGCWKVuMStJ/OZII4WkFiy5zzUA6ISLx// Y4WwlSQ+/p7PDlFvIPH+3HxmCNtaovHSH0YIW1ti2cLXzBA3CEqcnPmEZQKj+CwkK2YhaZ+F pH0WkvZZSNoXMLKuYuQoLU4ty003MtjECIypYxJsujsY97y0PMQowMGoxMM75bpvsBBrYllx Ze4hRmkOFiVx3i9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLJoeZ5xdUkIqHyaNvWm uRJ757PeRa94lxZ57tha+avtguXK9Uu6X75cIaKW61/l3sinOPHVmoIDf39d8p727Y6O8wRb xx0/f0Rw7Tdex8RQci0uVUfApPHzlDUWxao9Vgf2exS0ROVtaP2xZ7FyuPrmuNI5fJvLY/hK HrFUJVsuF14ZWqmrpMRSnJFoqMVcVJwIAKo6BySKAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/wV2jFrReLS8-lLs_kEtPdAFLI-g
Cc: OSPF List <ospf@ietf.org>
Subject: Re: [OSPF] 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:08:40 -0000

Hi Anton, 

I think I’m finally understanding the application of this draft. You state that the OSPF and OSPFv3 domains need not coincide. That is true but they must at least include the head-end of the LSPs for which you want to compute LSP paths. Do you mean this to also apply to multiple instances of the same AF? It would be a very ugly network design where they are part of the same routing domain. 

Thanks,
Acee

On Apr 16, 2014, at 6:56 AM, Anton Smirnov <asmirnov@cisco.com> wrote:

>   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 Smir
> -------- 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>
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf