Re: [OSPF] New Version Notification for draft-smirnov-ospf-xaf-te-01.txt
Anton Smirnov <asmirnov@cisco.com> Fri, 18 April 2014 09:05 UTC
Return-Path: <asmirnov@cisco.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 A6FB81A01FB for <ospf@ietfa.amsl.com>; Fri, 18 Apr 2014 02:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Level:
X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 124fAbNQferW for <ospf@ietfa.amsl.com>; Fri, 18 Apr 2014 02:05:39 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 41F481A0247 for <ospf@ietf.org>; Fri, 18 Apr 2014 02:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4388; q=dns/txt; s=iport; t=1397811935; x=1399021535; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3iVaIvWVRb4Da0eZHUK/RV1kkwRpjcpgOgI90btwSlM=; b=k0SsQHS55w0GkItiKMEtezOED2Mb8iDUte9AibwsxCB5PX9in34jGVGd yEWzhH1ej2z4gt2BpJuklF0k3Heb+lzh7OiqvnmGLbrbIwlznNW17Tc1O /ZdrxLHDVVzaH5rhmILHbZzHFrmujP/ZtJZ92IgWroYxai8KiHQ9sGBXm c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFABPqUFOtJssW/2dsb2JhbABZg0FRvDqHOIE3dIIlAQEBAwEBAQEvAQU2CQEBDAQLEQMBAgEJFg8JAwIBAgEVKAgGDQEFAgEBBRKHWQgIBcwzF44OVAcGhDIBA5UAg26BN5EYgzM7
X-IronPort-AV: E=Sophos;i="4.97,883,1389744000"; d="scan'208";a="14881584"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 18 Apr 2014 09:05:34 +0000
Received: from as-lnx.cisco.com (ams-asmirnov-8714.cisco.com [10.55.140.85]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3I95WvV023066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 Apr 2014 09:05:34 GMT
Message-ID: <5350EADB.3050003@cisco.com>
Date: Fri, 18 Apr 2014 11:05:31 +0200
From: Anton Smirnov <asmirnov@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Acee Lindem <acee.lindem@ericsson.com>
References: <20140414204801.6069.46438.idtracker@ietfa.amsl.com> <534E61F0.4040105@cisco.com> <9DEEF3C3-BAAB-4019-82B9-82F5C392A691@ericsson.com>
In-Reply-To: <9DEEF3C3-BAAB-4019-82B9-82F5C392A691@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Authenticated-User: asmirnov
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/2SfnLkKyPXS97CLjxV7ytoTpHA4
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: Fri, 18 Apr 2014 09:05:41 -0000
Hi Acee, > 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. This technique allows one protocol instance to use TEs signaled by another protocol instance. Choice of instances may indeed be quite bizarre - for example, the same technique may be used to signal TEs via ISIS/IPv4 AF and be used for routing by OSPFv3/IPv6 AF. Possibility of making such design does not mean that this design makes practical sense or that we should care about it. As authors see it, the main application now would be to signal TEs via OSPFv2/IPv4 AF and use them for routing in OSPFv3/IPv6 AF. And, in more distant future, vice verse - signal TEs via OSPFv3/IPv6 AF and use them for routing in OSPFv2/IPv4 AF. That may be needed when OSPFv2 is being phased out of the network - but of course we are very far from this point yet. While other combinations are theoretically possible we do not see practical value in them. Anton On 04/17/2014 11:08 PM, Acee Lindem wrote: > 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 >
- [OSPF] New Version Notification for draft-smirnov… Anton Smirnov
- Re: [OSPF] New Version Notification for draft-smi… Acee Lindem
- [OSPF] Fwd: New Version Notification for draft-sm… Acee Lindem
- Re: [OSPF] New Version Notification for draft-smi… Anton Smirnov