Re: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering Tunnels" - draft-ietf-ospf-xaf-te-05

Anton Smirnov <> Wed, 27 February 2019 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3E5C13108F; Wed, 27 Feb 2019 13:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f29gbzb7efK8; Wed, 27 Feb 2019 13:31:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 598221292F1; Wed, 27 Feb 2019 13:31:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3439; q=dns/txt; s=iport; t=1551303101; x=1552512701; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=o+xSOYkAqWtjRAWVubIeqjgVmQQ+PpPCcnrBnFbs0Bw=; b=cEMrWDOiYGssvIpDuZT891EEerxKeGPxAUILa01c9V2a13OZxWtdBAvF IBKbvDtbD//3SnMuy+ylqYO5YUtJWUCLcwXC2C/I/VqJYfy8Mj6/+ipc3 dOhPjG3G9GdWf5hniPzGX1ORsjOvd6mi/YkwNm+qK4JyvxcKpMJg5kqy1 c=;
X-IronPort-AV: E=Sophos;i="5.58,420,1544486400"; d="scan'208";a="10387344"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2019 21:31:39 +0000
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x1RLVcQN023821 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2019 21:31:39 GMT
To: Alexander Okonnikov <>, "Acee Lindem (acee)" <>
Cc: "" <>, "" <>, Gunter Van de Velde <>, "Ketan Talaulikar (ketant)" <>
References: <> <>
From: Anton Smirnov <>
Organization: Cisco Systems
Message-ID: <>
Date: Wed, 27 Feb 2019 22:31:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Authenticated-User: asmirnov
Archived-At: <>
Subject: Re: [Lsr] "OSPF Routing with Cross-Address Family Traffic Engineering Tunnels" - draft-ietf-ospf-xaf-te-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Feb 2019 21:31:44 -0000

    Hi Alexander,
    see some answers inline.


On 02/08/19 11:25, Alexander Okonnikov wrote:
> Hi Acee,
> For me current version doesn't change the solution. My comments are follow:
> 1.  Introduction
> "TE Extensions to OSPFv2 [RFC3630] and OSPFv3 [RFC5329] have been 
> described to support intra-area TE in IPv4 and IPv6 networks, 
> respectively.  In both cases, the TE database provides a tight coupling 
> between the routed protocol and advertised TE signaling information.  In 
> other words, any use of the TE link state database is limited to IPv4 
> for OSPFv2 [RFC2328] and IPv6 for OSPFv3 [RFC5340]."
> What is meant for "routed protocol"? Is it passenger protocol of RSVP-TE 
> LSPs, protocol used as a transport for RSVP signaling, protocol for 
> which OSPFv2/OSPFv3 calculate routes?

"Routed protocol" here refers to "protocol for which OSPFv2/OSPFv3 
calculate routes".
Words "routed protocol" signify protocol that is subject of somebody's 
action, so this wording should exclude options like "protocol used as a 
transport for RSVP signaling" (here protocol is object, not subject).

 >  What does mean "TEDB is limited
 > to IPv4/IPv6"? Is it limited to choose IPv4/IPv6 as a transport for
 > RSVP-TE LSP signaling?

Among other things selection of [RFC3630] versus [RFC5329] defines if 
IPv4 or IPv6 will be used as a transport for RSVP-TE LSP signaling. But 
not limited to only this, all other IPv4 vs IPv6 selections become 
predefined. As it is written in the draft, currently there exists "a 
tight coupling between the routed protocol and advertised TE signaling 

> "For example, an LSP created based on MPLS TE information propagated by 
> an OSPFv2 instance can be used to transport both IPv4 and IPv6 traffic, 
> as opposed to using both OSPFv2 and OSPFv3 to provision a separate LSP 
> for each address family."
> An LSP created based on TEDB from OSPFv2 can be used to transport IPv4 
> and IPv6 without extensions, proposed in the draft. We are not obligated 
> to signal RSVP-TE LSPs from OSPFv2 TEDB for IPv4 traffic and other 
> RSVP-TE LSPs from OSPFv3 TEDB for IPv6 traffic. RSVP-TE LSPs signaled 
> based on TEDB from either - OSPFv2 or OSPFv3 - can be used for transport 
> either - IPv4 or IPv6 - traffic. I.e. payload of RSVP-TE LSP and 
> transport protocol for its signaling are not obligated to be the same. I 
> guess that authors meant that an LSP, based on MPLS TE from OSPFv2, can 
> be used for calculation of shortcuts by OSPFv2, and not by OSPFv3.

Correct. Both the description of what protocol can go over what tunnel 
and interpretation of the text are correct.

> 3.  Operation
> "A node that implements X-AF routing SHOULD advertise, in the 
> corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6 
> addresses local to the router that can be used by Constrained SPF (CSPF) 
> to calculate MPLS TE LSPs."
>  From section 1 we assume that X-AF is used for calculation of 
> shortcuts. Why does the draft say here about calculation of TE LSPs by CSPF?

CSPF as part of the whole procedure computing MPLS TE path among other 
things is defined in terms what IP addresses it uses to define tunnel 
tail-end. Reference to the CSPF is made to define set of IP addresses 
that would be of interest to X-AF algorithm.