Re: [OSPF] draft-atlas-ospf-mrt-02

Acee Lindem <acee@lindem.com> Mon, 14 July 2014 19:47 UTC

Return-Path: <acee@lindem.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 484521A00B8 for <ospf@ietfa.amsl.com>; Mon, 14 Jul 2014 12:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 fk64K1s1MVjN for <ospf@ietfa.amsl.com>; Mon, 14 Jul 2014 12:47:51 -0700 (PDT)
Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.232]) by ietfa.amsl.com (Postfix) with ESMTP id 363FA1A00A3 for <ospf@ietf.org>; Mon, 14 Jul 2014 12:47:51 -0700 (PDT)
Received: from [65.190.6.125] ([65.190.6.125:34054] helo=[10.0.1.6]) by cdptpa-oedge01 (envelope-from <acee@lindem.com>) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 60/55-14952-5E334C35; Mon, 14 Jul 2014 19:47:50 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Acee Lindem <acee@lindem.com>
In-Reply-To: <c6cbd43d70c94595ad3c5a24f3dcd6c0@BLUPR05MB292.namprd05.prod.outlook.com>
Date: Mon, 14 Jul 2014 15:47:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E91754D-31E0-47D5-B516-0D89E33B502E@lindem.com>
References: <02df01cf9917$9b05a650$d110f2f0$@riw.us> <c6cbd43d70c94595ad3c5a24f3dcd6c0@BLUPR05MB292.namprd05.prod.outlook.com>
To: Chris Bowers <cbowers@juniper.net>
X-Mailer: Apple Mail (2.1878.6)
X-RR-Connecting-IP: 107.14.168.118:25
X-Cloudmark-Score: 0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/Qq5fu2C9Cia3-i0Sjbn__n-Od9E
Cc: OSPF List <ospf@ietf.org>, Alia Atlas <akatlas@juniper.net>
Subject: Re: [OSPF] draft-atlas-ospf-mrt-02
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: Mon, 14 Jul 2014 19:47:53 -0000

Hi Chris, Shraddha,  

On Jul 14, 2014, at 3:36 PM, Chris Bowers <cbowers@juniper.net> wrote:

> (The response to this question ended up off of the list, so I'm posting it to continue the discussion on the list.) 
> 
> Russ,
> 
> I see your point in link information being carried in Node related LSA.
> 
> The link information is carried in Router LSA and it's not extendible to carry any other information.
> Since RI-LSA is modeled as an extension to Router LSA, my idea was to tag the additional link information With new TLV in RI-LSA.
> 
> Another approach could have been to define a new LSA type and originate a new LSA for each link which is in-eligible to participate in MRT. A separate LSA for each link to advertise ineligibility looks suboptimal considering the amount of state machine/data structure that needs to be maintained for a separate LSA.
> 
>>> It seems like it might be better to move this bit of information into the TLV where the actual link state is advertised in some way.
> 
> Link related information is advertised in OSPF-TE opaque LSAs as well. MRT could run on non-TE enabled networks as well, so it may not be appropriate to use TE LSAs.
> 
> Let me know if you think we could stuff-in in existing LSAs or we should go with new LSA altogether.

Do NOT use the OSPF RI LSA for link information. Rather than define a new LSA, use the OSPFv2 Extended-Link opaque LSA defined in https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/

Thanks,
Acee



> 
> Rgds,
> Shraddha
> 
> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Russ White
> Sent: Sunday, July 06, 2014 7:41 AM
> To: 'OSPF List'
> Cc: Alia Atlas
> Subject: [OSPF] draft-atlas-ospf-mrt-02
> 
> 
> Just one question/comment on this draft -- In section 6.1, MRT-Ineligible Links TLV for OSPFv2, the draft says there should be a new TLV in the router capabilities LSA that advertises links not to be included in the MRT calculation (excluded links). I'm not certain why an option isn't used in the LSA header for this, instead. Two things that seem strange to me:
> 
> - The exclusion of a link is a link property, not a router property, so I'm not certain why this would be advertised as a property of the OSPF router.
> This seems to muddy the line between router and properties and link properties in a way that sets the stage for make the router capabilities just another area into which to stuff various bits of information we can't find a home for elsewhere.
> 
> - If you modify a specific link state, then you must advertise two TLVs, or rather two LSAs, rather than one. Thus these two pieces of information must be connected in a local database, but advertised separately, with all the coordination/etc. that implies.
> 
> It seems like it might be better to move this bit of information into the TLV where the actual link state is advertised in some way.
> 
> :-)
> 
> Russ
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf