Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 09 July 2018 20:24 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E44131065; Mon, 9 Jul 2018 13:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 SW_R6NQaVoYn; Mon, 9 Jul 2018 13:24:39 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F49131057; Mon, 9 Jul 2018 13:24:39 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id p129-v6so7013193ywg.7; Mon, 09 Jul 2018 13:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=OnPhfTDFpkr7d6F92YrYoUdH9zEgjY2Z1rj9BKWouxE=; b=ePcP8jQdM08MAL2ultvyYkOFxWE7Sb+uPHu2MdHESB6mcKBiW4Zd0JLXEbbb8IlKQB 1UnOjy4NW69bR4uyCcdyUxMZ1BdZAy/voZqxo1aDUZXWkWANYDPEupLKua/WW3zSJWht VTj5AkrMATRO2OEIuhF0RyjTysercURwrQABEh9fCdXmPtjy4y34+NpG9c1qMS5LHdgt LoVv0fI1egi3EOcLqt7az7q90efL52OIE/FZCQVLDdcimjPjJWSyNUiwLHCKhq4drwjB pGFwtgK9NdJU3ZeBq107axVhWfZ4qoUgesvGdoIGG5LpmTAQCZshyzl5kd7NSN9BtnaC USaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=OnPhfTDFpkr7d6F92YrYoUdH9zEgjY2Z1rj9BKWouxE=; b=uk40cjsdzL2GIIsUmSqZyjdis1U5JH6Oj3NthZenIuQbIN2apF9QnjLD6eNz1mtcWj SRHx5vwiWYG5R5XoolQDIMKvYe1Hr9fTwFnPPTIlwlMIKykIGgbSSkS3Exd83vMd0Cws 7INxmPvfqG33d4/PLJFWdyzxBODJbbtbq7CwL0r/D9Qkrla2k1osxPt/LrZv6HtvAC8D L8ki/Er5ERFUiqAmHUfMaCN6wu+REuwCwiVTbfYgaFK0lj/TO6xmwT2duIxOzAhyb9x/ r8TYMW1cgo9t+xCD2ulwTdDKePuDMRe4GWXYVEwgp0kt5bRwWM1N4r3hr/I3BP0YlINX A1jQ==
X-Gm-Message-State: APt69E0LFDFRVUpM1ur8GPQpU0ZjhpdwZ8CjH4vONLy5UAn3cjatkkC1 gptVVh7YWasSnVdt4BQNNNw=
X-Google-Smtp-Source: AAOMgpcRAagnTaD0QQWMQ2P+EjHrI2snfIn+OkS9YV8XRCgMvvuOxsr2dvLObdy9GlDjA8sbtupH3g==
X-Received: by 2002:a81:1cd5:: with SMTP id c204-v6mr10998225ywc.335.1531167878122; Mon, 09 Jul 2018 13:24:38 -0700 (PDT)
Received: from [135.227.239.108] ([66.201.62.254]) by smtp.gmail.com with ESMTPSA id 1-v6sm6554373ywr.24.2018.07.09.13.24.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 13:24:37 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.e.1.180613
Date: Mon, 09 Jul 2018 13:24:33 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Message-ID: <78D707C9-6DC2-459F-81E4-A53B46F1F019@gmail.com>
Thread-Topic: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3613987477_1145753576"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qLrUgtk5zz0Fh9TfjysYd-wxG3k>
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2018 20:24:43 -0000

Hi Linda,

 

Why would you want to build what you are trying to do into protocol?

#1 local policy

#2  NO_ADVERTISE does that exactly 

 

Cheers,

Jeff

 

From: Idr <idr-bounces@ietf.org> on behalf of Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, July 9, 2018 at 13:14
To: Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

 

Eric, 

 

draft-ietf-idr-tunnel-encaps-09 discussed ways to resolve conflicts of multiple UPDATE messages with Tunnel Encap attributes. 

 

Is it possible to have following capability? 
Have a bit indicating a specific UPDATE is from authoritative source, therefore overwrite all other Tunnel Attributes for the Prefix X to avoid recursive next hop issues and tunnel selection at the receiving Router? 
Have a bit indicating that a specific UPDATE only contain Tunnel attributes for the receiving Router, therefore can’t be forwarded? 
 

You said that SAFI 7 is deprecated because no one seemed interested in using it. We are very interested in using it because 
it can be easily distinguished from normal  BGP UPDATE
 The receiving router doesn’t have to “Filter” the tunnel attributes before forwarding to others.  
Can even be used for passing reconfigured IPsec keys to two ends of a tunnel. 
 

Therefore we think SAFI 7 should be reserved. 

 

Thanks, Linda Dunbar

 

From: Eric C Rosen [mailto:erosen@juniper.net] 
Sent: Tuesday, July 03, 2018 12:21 PM
To: Linda Dunbar <linda.dunbar@huawei.com>; idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org
Subject: Re: What are side effect for having Encap SAFI? can draft-ietf-idr-tunnel-encaps-09 preserve trigger tunnel creation before VPN is established?

 

On 7/2/2018 6:31 PM, Linda Dunbar wrote:



Eric, IDR group, 

 

It is indicated that RFC5512 is to be replaced by draft-ietf-idr-tunnel-encaps. But draft-ietf-idr-tunnel-encaps-09 stated that it deprecates the

Encapsulation SAFI. 

 

We find the Encapsulation SAFI is quite useful for CPE based EVPN.  For example, a Controller (say RR) can send an update with Encapsulation SAFI to two end points to trigger a tunnel establishment between them. 

What are side effect for having Encap SAFI? Can we preserve it in draft-ietf-idr-tunnel-encaps?

 

Thanks, Linda Dunbar

 


SAFI 7 was deprecated because no one seemed interested in using it, it creates additional operational issues, there is no real need for it, and it was discouraging folks from actually using the Tunnel Encapsulation attribute.  This is discussed briefly in section 1.2 of the draft.

You can get a similar effect by using the technique described in section 7 of the draft.

If PE1 is the egress point of a tunnel, have PE1 originate an UPDATE whose NLRI is PE1's loopback address.  Put the Tunnel Encapsulation attribute (with PE1 as remote endpoint) on this UPDATE.  (The next hop field of this UPDATE doesn't really matter, as long as it is resolvable.)  When PE1 originates VPN routes, it sets the next hop to be its loopback address.  Per section 7, this will result in packets being sent to PE1 though the specified tunnel.

 

_______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr