Re: [spring] Implementation Report on draft-ietf-spring-segment-routing-ldp-interop

"Ahmed Bashandy (bashandy)" <bashandy@cisco.com> Fri, 13 November 2015 01:03 UTC

Return-Path: <bashandy@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A381A1B3BB5 for <spring@ietfa.amsl.com>; Thu, 12 Nov 2015 17:03:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 yrWe7Eqq8nnE for <spring@ietfa.amsl.com>; Thu, 12 Nov 2015 17:03:45 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99AD81B3BB0 for <spring@ietf.org>; Thu, 12 Nov 2015 17:03:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7330; q=dns/txt; s=iport; t=1447376625; x=1448586225; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=foX5K2hp8pP4i+uC/ycO+Ip3VvL5km+XhzOB3fbhfpQ=; b=aRpBAExEvGs6XaTmFHWRZMM0DSz5h0cS+GiR1mog2PG0VtqJKDltCWPI pZAQohVKigelMIststuWc6noxFkgm1WfyMA95gDzAdGTupQkJUvQje3pa TZxI5UMhCUEtU4Vpb20y55wuxnldp2hWS30bUnK4Pgrbfe8tr9crrQxUa w=;
X-IronPort-AV: E=Sophos; i="5.20,284,1444694400"; d="scan'208,217"; a="46379134"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 13 Nov 2015 01:03:45 +0000
Received: from [10.32.173.22] ([10.32.173.22]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tAD13iWQ019142; Fri, 13 Nov 2015 01:03:44 GMT
Message-ID: <564536F0.4030209@cisco.com>
Date: Thu, 12 Nov 2015 17:03:44 -0800
From: "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Lizhenbin <lizhenbin@huawei.com>, "spring@ietf.org" <spring@ietf.org>
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA61266@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA61266@nkgeml506-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------080502090600090708040609"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spring/Xpcwjo0uwXtmlHJzwlixOj3M5qA>
Subject: Re: [spring] Implementation Report on draft-ietf-spring-segment-routing-ldp-interop
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 01:03:47 -0000

Hi Robin

The mapping server is already implemented. And it is not that complex at all

As for the support of inter-AS option "C", there are two solutions
(1) "draft-filsfils-spring-sr-recursing-info-01" provides a way to use 
the prefix-SID of one address for another one. So refering to the second 
figure in the your draft "draft-li-spring-compare-sr-ldp-rsvpte-00", 
ASBR12 can  inject the IP addresses of "PE21" and "PE22" in the IGP of 
AS1 and use the IP address of ASBR11 itself as the "Recursing SID Address".
(2) "draft-ietf-spring-segment-routing-ldp-interop" suggests using 
BGP-LU to distribute the remote domain information as Jon Mitchell 
mention in his email. At the first glance, it may seem like an issue for 
some platforms. However, as it is mentioned in 
"draft-bashandy-rtgwg-bgp-pic-02" which was presented in the last IETF, 
it is actually very easy to flatten a 2 level recursion into a single 
level of recursion, thereby supporting any hardware capability

Thanks

Ahmed



On 11/2/2015 5:21 PM, Lizhenbin wrote:
>
> Hi Folks,
>
> I proposed my concern on the implementation of interoperability 
> between LDP and SR again in IETF. I also would like to remind you of 
> my draft again:
>
> https://tools.ietf.org/html/draft-li-spring-compare-sr-ldp-rsvpte-00
>
> In this draft I explained the possible challenges of SR comparing LDP. 
> And in sec 6 I summary the possible challenge of Interoperability 
> between SR and LDP/RSVP-TE. Until now I believe that there will be 
> much challege for the implementation. In fact in order to solve the 
> possbile issue I mentioned in the draft, the mapping server has been 
> introduced. Is it some central-control based solution in the IGP/LDP 
> distributed environment? I worried that there still more issues which 
> have to be solved and propose great challenge for the implementor on 
> the feature and when new mechanisms are introduced they will propose 
> new challenges again. If so, this may be nightmare for the developer 
> of the feature. Hope if there were the implementation the 
> implementation report on 
> draft-ietf-spring-segment-routing-ldp-interop-00 can be publised 
> accomanying the draft to demonstrate what can be done and maye what 
> can not be done. This will be much helpful to the implementors and 
> operators to consider their possible choice to cope with this interop 
> issue: take the challenge, leave it or replace the LDP network with SR 
> all at once without introducing the interoperability issue.
>
> Best Regards,
>
> Zhenbin(Robin)
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring