Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03

Peter Psenak <ppsenak@cisco.com> Wed, 03 December 2014 08:30 UTC

Return-Path: <ppsenak@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 7EB921A01A9 for <ospf@ietfa.amsl.com>; Wed, 3 Dec 2014 00:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, 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 kJ2EzrALjyru for <ospf@ietfa.amsl.com>; Wed, 3 Dec 2014 00:30:41 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0211A017E for <ospf@ietf.org>; Wed, 3 Dec 2014 00:30:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4344; q=dns/txt; s=iport; t=1417595441; x=1418805041; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7Kg5yB2HqmjCc0i13SqqXYPfKJFehaZysomZ8hF++l4=; b=LwWlmmFWE8OMRLgUyPNq+Ju9+yvE0HimQjgI3ys93EpkrAc2E6mfGLZ2 Q07tRmN84b8cZFUBaoMhBtWlD0C2v/UVDxyGTP5ZEq0WpY+GL2Eh/FtQD tdjXxsmgPVpqxbwudPwPicatOqXCqFTkZQDVb4ROF5EXKEeRRWjJHNHtd o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAOTIflStJV2b/2dsb2JhbABbgweBK80OAoESFgEBAQEBfYQCAQEBAwE4LxEBDAQLEQQBAQEJFggHCQMCAQIBNAkIBgEMAQUCAQGIMwnWCgEBAQEBAQEBAQEBAQEBAQEBAQEBAReQbwcGhEIBBJwGgSyDOIJijVuCAiCBWj4wgkcBAQE
X-IronPort-AV: E=Sophos;i="5.07,506,1413244800"; d="scan'208";a="377132352"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 03 Dec 2014 08:30:40 +0000
Received: from [10.55.51.195] (ams-ppsenak-8712.cisco.com [10.55.51.195]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB38UcHk001737; Wed, 3 Dec 2014 08:30:39 GMT
Message-ID: <547ECA2E.9030808@cisco.com>
Date: Wed, 03 Dec 2014 09:30:38 +0100
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Shraddha Hegde <shraddha@juniper.net>, "draft-ietf-ospf-segment-routing-extensions@tools.ietf.org" <draft-ietf-ospf-segment-routing-extensions@tools.ietf.org>
References: <64c8be7dc5744779b0a119ac0584777c@BY1PR0501MB1381.namprd05.prod.outlook.com> <547DF219.4020500@cisco.com> <BY1PR0501MB13814BFB715CA30C38D4FAF0D57B0@BY1PR0501MB1381.namprd05.prod.outlook.com>
In-Reply-To: <BY1PR0501MB13814BFB715CA30C38D4FAF0D57B0@BY1PR0501MB1381.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ktIF2nTVC3vGYuWfcle4mQi2LWI
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] draft-ietf-ospf-segment-routing-extensions-03
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: Wed, 03 Dec 2014 08:30:43 -0000

Shraddha,

please see inline:

On 12/3/14 06:10 , Shraddha Hegde wrote:
> Peter,
>
> <Snipped to open points>
>
>>         Shouldn't each node in broadcast link originate LAN adj-SID and
>> advertise label to all other nodes on the link?
>
> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to
> non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN.
>
> <Shraddha> Is there a specific reason to advertise adj-sid for the DR and LAN adj-sid for non-DR?
>                        Is it because the Neighbor-ID is already part of Extended link TLV and we are saving 4 bytes?

for adjacency on 2p2 link and adjacency to DR, link-type and link-id in 
Extended link TLV is used. For non-DR case, we need to describe the 
neighbor by neighbor-id, so we needed a new sub-TLV to do that.

>
>
>> I would think that we should have "route type" as in Extended prefix TLV
>> instead of just having a bit indicating "inter area"
>
> route-type would be misleading for range, as single range can include
> prefixes of various types (intra, inter, external). We have discussed
> this between authors and we agreed route-type is not the right way.
>
> <Shraddha> The prefix range TLV is carried in Extended prefix LSA which is based on scope of flooding.
>                         If we combine intra/inter/external in the prefix range TLV, what scope is used for flooding the extended prefix LSA?

prefix range is used for SR mapping server to optimize the SID 
advertisement. Prefix range as such does not need to have a route type, 
because it is not advertising a reachability. One can use domain wide 
flooding for certain external prefix, but use regular inter-area 
distribution for prefix range that is covering the external prefix.

thanks,
Peter

>
>
> Rgds
> Shraddha
>
> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Tuesday, December 02, 2014 10:39 PM
> To: Shraddha Hegde; draft-ietf-ospf-segment-routing-extensions@tools.ietf.org
> Cc: OSPF WG List
> Subject: Re: draft-ietf-ospf-segment-routing-extensions-03
>
> Shraddha,
>
> please see inline:
>
> On 12/2/14 17:50 , Shraddha Hegde wrote:
>> Authors,
>> Some  comments on the draft.
>>
>>   1. The draft refers to the various use cases in the use case document
>>      in I-D.filsfils-rtgwg-segment-routing. It's useful to mention the
>>      section of the use case draft which is applicable for each reference
>>      instead of giving generic reference.
>
> sure, we can add that.
>
>>   2. Section 7.2 LAN Adj-sid sub TLV:
>>
>> Based on the description of the text it appears that the LAN AdjSID
>> Sub TLV can contain multiple neighbor-ID /SID pairs based on the nodes
>> attached to a broadcast network. The TLV diagram should depict
>> carrying multiple such pairs.
>
> no. LAN AdjSID Sub TLV only advertises a adj-SID for a single neighbor.
> If you have more non-DR neighbors, you need to advertise multiple LAN Adj-SID Sub-TLVs.
>
>
>>          "It is used to advertise a SID/Label for an
>>      adjacency to a non-DR node on a broadcast or NBMA network."
>> Does the above statement mean only DR originates the LAN-Adj SIDand
>> advertises label to non-DR nodes?
>
> no.
>
>>         Shouldn't each node in broadcast link originate LAN adj-SID and
>> advertise label to all other nodes on the link?
>
> For the adjacency to DR, Adj-SID Sub-TLV is used. For the adjacency to
> non-DR LAN Adj-SID Sub-TLV is used. It's done all all nodes on the LAN.
>
>>
>>   3. Adj-Sid sub TLV section 7.1:
>>
>> Description of V-flag mentions Prefix-SID,  it should be changed to Adj-SID.
>
> good catch, will correct.
>
>>
>>   4. Section 4: Extended prefix range TLV is very similar to Extended
>>      prefix TLV just that it has additional range associated with it.
>
> yes, that is correct.
>
>>
>> I would think that we should have "route type" as in Extended prefix TLV
>> instead of just having a bit indicating "inter area"
>
> route-type would be misleading for range, as single range can include
> prefixes of various types (intra, inter, external). We have discussed
> this between authors and we agreed route-type is not the right way.
>
> thanks,
> Peter
>
>> Rgds
>> Shraddha
>
> .
>