Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Fri, 10 February 2017 15:26 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7291299CD; Fri, 10 Feb 2017 07:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0KC7GbSBaz_p; Fri, 10 Feb 2017 07:25:59 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692B31293EB; Fri, 10 Feb 2017 07:25:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10604; q=dns/txt; s=iport; t=1486740359; x=1487949959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KHtv8s9NVN69B0ibP3mkuCpbt21Z42kGrhLswfHuIBc=; b=P4iSRa8Vev3ZYIcqX+EzaMcN7GdMnxak45vZBOnudycaQVqwFBXNfZla H7aNJTilmRABmwQ4BnxGjCNjK8OKJ+xQzf1SdacG60m3KKj3UgNOoZKYz 1uxoQSCv9cbt6MwZQuAIcVv0taX2gj+FWuELEFBxgamZkv/Ct0/5R0frm E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAQAn251Y/5BdJa1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMoKoFqB4NSigiSDJU2gg2GIgIagl8/GAECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQEDASMRRQUHBAIBCBEBAwEBAQICIwMCAgIwFAECBggBAQQOBYlwCK98giWLU?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4VBggWCaoQsKIMGLoIxAQSIfpJ0AYo?= =?us-ascii?q?OiAWBe4UXiDqBOYgsH4pJAR84fk8VPBEBhDIdgWF1iRKBDAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.35,142,1484006400"; d="scan'208";a="383148800"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 15:25:47 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1AFPi2k014174 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 15:25:46 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 10:25:44 -0500
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Fri, 10 Feb 2017 10:25:44 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>
Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH
Thread-Topic: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH
Thread-Index: AdKC3shnhVQAsSeqr02qRN73fuHSc///1RUA//7E0wCAAk1YgP//Wi5ggAG4tAA=
Date: Fri, 10 Feb 2017 15:25:44 +0000
Message-ID: <F220EFEC-FFE3-413D-B9ED-C3319AB3FE0B@cisco.com>
References: <73BFDDFFF499304EB26FE5FDEF20F7885086FA74@blreml501-mbx> <3E1CCF0A-41E5-49E9-82FA-BC96F689A69D@cisco.com> <73BFDDFFF499304EB26FE5FDEF20F7885086FE9C@blreml501-mbx> <2DE89697-41FA-4389-9CDE-A91B7ADE37D1@cisco.com> <73BFDDFFF499304EB26FE5FDEF20F788508700B4@blreml501-mbx>
In-Reply-To: <73BFDDFFF499304EB26FE5FDEF20F788508700B4@blreml501-mbx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.196.1]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8C4835E588589145B1AD58FE977887EE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gSF5ml5YLdPcI_1LskHZ_RX7IpE>
Cc: "draft-ietf-ospf-ospfv3-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-ospfv3-segment-routing-extensions@tools.ietf.org>, "ospf@ietf.org" <ospf@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "draft-ietf-6man-segment-routing-header@ietf.org" <draft-ietf-6man-segment-routing-header@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Feb 2017 15:26:01 -0000

you are right. The algorithm needs to be different for the adj-sid. It is part of the changes I’m working at for the next revision of the draft.

Typically, the “action” in the algorithm (for the adj-sid) consists of a forwarding instruction out to the interface the adj-sid is allocated to.

s.


> On Feb 10, 2017, at 4:18 PM, Veerendranatha Reddy Vallem <veerendranatharv@huawei.com> wrote:
> 
> Dear Previdi,
> SRH may carry Adj Segment and Special segments (128 IPv6 prefixes)  along with Node Segments.
> 
> Ex: Consider below Topology
> 
> 
>                        / B ------ C------- D\                                                                                                   
>                      /        Fadj| |                 \                                                                                                
> X --------A                   | |                 H----- Y                                                                                       
>                   \                   | |              /                                                                                               
>                     \   E ----  F ----- G  /                                                                                                   
> 
> 
> 
> 
>  At Node X         		At Node A,                            		At node C,     while forwarding to F (C need to decrement segments to twice, one for Fadj and other for F)                                                                                          
> IPv6 Hdr                              Ipv6 Hdr                                 		 IPv6 Hdr
> DA= Y SA=X                      DA= C SA=X                             		DA= F SA=X                                                                                          
>          		             SRHdr (segment left 4)        		SRHdr (segment left 2)                                                                              
>         		            Y,H,F,Fadj,C                            	                Y,H,F,Fadj,C                                                                                        
> 
> While processing this type of SRH, I feel existing algorithm may be required to modify to add recursive look up to process Adj Segment/Special segment as below. (Based on above example)
> 
> Existing algorithm: (As per section 4.3), 
> 
>   1.   IF DA = myself (segment endpoint)
>   2.      IF Segments Left > 0 THEN
>              decrement Segments Left
>              update DA with Segment List[Segments Left]
>   3.      ELSE continue IPv6 processing of the packet
>                End of processing.
>   4.   Forward the packet out
> 
> Proposed Modification:
> 
>    1.   IF DA = myself (segment endpoint)
>   2.      IF   Segments Left > 0  THEN
>              decrement Segments Left
>               do
>               IF Segment List[Segments Left]= Adj-Segment/Special Segment originated by myself
>                     Trigger the action as per Segment (Ex: if it is Adj Segment, identify interface to forward, if segment is for the service,  trigger for service)
>                     Decrement Segments Left
>               ELSE 
>                      Update DA with Segment List[Segments Left]
>                       break;
>             while (Segments Left > 0)    
> 
>   3.      ELSE continue IPv6 processing of the packet
>                End of processing.
>   4.   Forward the packet out
> 
> If SRH is having combination of Node and Adj SID then recursive look up to be 2 times maximum at each IPv6 SR supported nodes 
> If Service Segments are added to SRH, then may be multiple recursive look ups, since it may require to handle multiple services by same node.
> 
> Please check and let me know your opinion.
> 
> Thanks & Regards,
> Veerendranath
> 	
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] 
> Sent: 10 February 2017 15:02
> To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>
> Cc: draft-ietf-6man-segment-routing-header@ietf.org; draft-ietf-ospf-ospfv3-segment-routing-extensions@tools.ietf.org; ospf@ietf.org; ipv6@ietf.org
> Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH
> 
> Hi Veerendranath,
> 
> yes, an SR-IPv6 SID is a 128-bit IPv6 addresses. 
> 
> The semantic associated to the SID is given by the control plane. We have already documented the signaling of the SIDs in ISIS, OSPF and BGP. Currently we have defined Node-SIDs (representing a node) and Adjacency-SIDs (instruction to forward out to the interface the SID is allocated to).
> 
> In the IPv6 dataplane a SID being an IPv6 address, it makes the SID a global IPv6 address (even in the case of Adj-SIDs). This of course is orthogonal to the control plane that may or may not advertise such address.
> 
> I.e., you may have an Adj-SID as a global IPv6 address that it is not advertised by any routing protocol in the network (which implies of course that the packet will have to first reach the node using a node-SID).
> 
> The use of LL addresses as SID has not been contemplated for the simple reason that a router may well allocated the same address to all links so it is not a reliable mechanism for forwarding. This will be fixed in the next revision of the ospfv3 draft (isis draft is ok).
> 
> s.
> 
> 
> 
>> On Feb 10, 2017, at 7:37 AM, Veerendranatha Reddy Vallem <veerendranatharv@huawei.com> wrote:
>> 
>> Dear Previdi,
>> Thanks for your reply. 
>> 
>> As per first version of draft, Adj-SID is also  IPv6 prefix. 
>> 
>> 4.2.2.  Adjacency-SID
>> 
>>  The Adjacency-SID identifies a given interface.  In the SR
>>  architecture a node may advertise one or more Adj-SIDs allocated to a
>>  given interface so to force the forwarding of the packet (when
>>  received with that particular Adj-SID) into the interface, regardless
>>  the routing entry for the packet destination.  The same is defined
>>  for SR-IPv6: a node may advertise a given IPv6 prefix which is
>>  associated to the SR semantic of "send out the packet to the
>>  interface this prefix is allocated to".  Here also, the SID is in
>>  fact the IPv6 prefix.
>> 
>> As per my understanding  "segment list in SRH is global IPv6 prefixes, If we need to include Adj SID to segment list then Adj-SID is also global IPv6 prefix". 
>> Please correct me if my understanding is wrong.
>> 
>> Thanks and Regards,
>> Veerendranath
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] 
>> Sent: 09 February 2017 22:41
>> To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>
>> Cc: draft-ietf-6man-segment-routing-header@ietf.org; draft-ietf-ospf-ospfv3-segment-routing-extensions@tools.ietf.org; ospf@ietf.org; ipv6@ietf.org
>> Subject: Re: [IPv6 SR] Regarding 128 bits IPv6 address in Segment List of SRH
>> 
>> Hi,
>> 
>> the first version of the draft (draft-previdi-6man-segment-routing-header) had a description of Node-SID and Adj-SID. Later, in order to simplify the document, we removed the descriptions and focused the document into the SRH format.
>> 
>> I think it will be helpful to re-introduce a section on the two main SID types (Node, Adjacency). I’m working on an update for the next version.
>> 
>> Thanks.
>> s.
>> 
>> 
>> 
>> 
>> 
>>> On Feb 9, 2017, at 5:02 PM, Veerendranatha Reddy Vallem <veerendranatharv@huawei.com> wrote:
>>> 
>>> Dear Authors,
>>> 
>>> I am requesting your clarification regarding usage of Adj-SID in SRH header
>> 
>