Re: Address Family Support in OSPFv3
Quaizar Vohra <qv@JUNIPER.NET> Mon, 23 June 2003 23:09 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14706 for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Jun 2003 19:09:36 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A2C920@cherry.ease.lsoft.com>; Mon, 23 Jun 2003 19:09:36 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46384156 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Jun 2003 19:09:35 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Jun 2003 19:09:35 -0400
Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5NN9Yu19817 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Jun 2003 16:09:34 -0700 (PDT) (envelope-from qv@juniper.net)
Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h5NN9Ye48201; Mon, 23 Jun 2003 16:09:34 -0700 (PDT) (envelope-from qv)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
References: <200306201740.h5KHe7n38087@fuinar.juniper.net> <000001c338e7$6c50a090$386545ab@amer.cisco.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Message-ID: <200306232309.h5NN9Ye48201@fuinar.juniper.net>
Date: Mon, 23 Jun 2003 16:09:34 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Quaizar Vohra <qv@JUNIPER.NET>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <000001c338e7$6c50a090$386545ab@amer.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit
Sina, Please see my comments inline. > Quaizar, > > ->I don't think creation and maintanence of extra adjs itself > ->is a problem, specially if N is 2 or 3. Also there is ongoing > ->development of IGP independent fast liveness protocols on > ->links (needs only one hello per link irrespective of whatever > ->other protocols, e.g. OSPF, are being run on the link). > ->Given that generally the world is heading in that direction, > ->it would be okay to run IGP hellos with larger intervals and > ->so hello maintanence is not a real problem. Even without that > ->it is not a problem. > > Independently of a fast liveliness protocols, you would have to send and > process Hellos. > Depending on the number of adj and topology, your N = 2/3 multiplied by > the number of adjacency could be significant. For example say you have a > Hub and Spoke with Hub router having 300 adj, if all Spoke participate > in say two other AF you would end up adding 600 more adj which is > unnecessary and significant 300 adjs or 600 adjs with hello interval of 10 seconds, have hardly had any impact on the CPU on one of the implementations I know about. > > ->Flooding and packet processing will be affected by a factor > ->of 2 atmost, as typically the database is dominated by LSAs > ->carrying prefix information. > > Again it all depends on your topology and environment, in case of AF > proposal not only type 1/2 but also intra-area-prefix will be optimized > since you carry more than one prefix within the intra-area-prefix-LSA ( > see below ) > > If you are in an environment that you are doing summarization then the > dominant LSA can be type 1/2 & intra-area-prefix-lsa therefore you could > gain more than a factor 2. In any case even a factor 2 multiplied by X > number of LSA could be significant If my dominant LSAs are just type 1/2 and intra-area-prefix, I wouldn't be very much concerned with a gain of 2, as even in a very large network, the number of these LSAs won't be very large. And much of this gain wouldn't even be realized due to differences in topology. > > ->So the only thing you are saving > ->on is advertising the same prefix LSAs for unicast and > ->multicast (for IPv4 and IPv6 you will have to anyway > ->originate different prefix LSAs. If you start carrying > ->different metric values for different AFs then the savings in > ->the router LSA is also gone (due to logical fragmentation if > ->your router LSAs are big and if not then you network is small > ->and this should not be a problem). > > In v3 each prefix is defined by { Prefix, Prefix length, Prefix Options > }, therefore you can add bits in Prefix Options to say to which AF a > prefix belongs and since you want to be backward compatible you can use > the NU bit to exclude the prefix from IPv6 unicast AF ( A short draft > will be available soon to demonstrate that for multicast AF) > > This mean that the prefix LSA encoding is flexible enough to carry > prefixes of different lengths (IPv6, IPv4 or whatever), as long as we > can distinguish the correct AF, by say looking at some Prefix Options > bits I am sure many of us already understand that. If you you suggesting that you will carry v4 and v6 prefixes in the same intra-area-prefix LSA, it is certainly doable with some amount of effort. But I still don't see any significant benefit out of it. As far as carrying unicast & multicast prefixes togather, I already counted that in in my last mail. > > -> > D) need a mapping of instance-ID to AF which is user > ->dependent and can > be prone to misconfiguration and > ->increase troubleshooting. > -> > ->Mapping AF to Instance shouldn't be that difficult. We could > ->reserve certain instance ids for the well known AFs. > > It is not sufficient to reserve some values, what happen if some of your > routers does not understand the given reserved values and you compute > the path through them ? Since even the hello packet will contain the instance-id, the adj shouldn't come up with a nbr who doesn't understand that instance-id value. This is nothing but SIN, everything is separate. > > ->On th other hand, changes like LG election and > ->AF-Functionality LSA or AF-inter-area-router LSA add > ->significant complexity to code. > > Significant? I do not believe adding two new LSA add significant > complexity. Further those LSA will be used by _all_ AF and are _generic_ It is not a question of just adding 2 more LSAs, it is a question of what is involved in generating them and processing them. What other parts of the code you are going to touch. What about LG election ? And what other bandages are yet to come ? > > -> > ->As far as changes in ISIS are concerned, the changes there > ->are more equivalent to using instance-ids then the changes in > ->your draft. > ->In fact all they do is replicate TLVs, once for > ->each topology. So they end up advertising proportionately > ->more LSPs, CSNPS etc. > > Not really, the _same_ LSP is advertised _once_ to sets of neighbors and > a neighbor use whatever TLV it needs. There is no extra adjacency and > extra-flooding because of different AF neighbor I already accepted in my last mail that there is no extra adjacecny. But there definitely is extra flooding. The more TLVs you add, the more LSP fragments you have and hence you have more to transmit. If for a node, there was only one LSP to advertise and it was significantly small that adding more TLVs for other AFs didn't require generating another one, then that is quite a degenerate case and my topology is significanlty small and I should be hardly worried with a gain of O(2). > > In fact in case of our proposal the LSA flooding is even more optimized > ( than ISIS) because type 1/2 are common to all AF further for prefix > information we can use the _same_ prefix LSA and add prefix specific AF > to the existing LSA so it is similar to adding TLV specific AF inside > LSP as in ISIS Yes, you are more optimal than ISIS (or supposedlty) but this optimality is achived in a significantly different way, i.e. by adding new functionality into the protocol. While ISIS chose to be simple and just replicate the TLVs, once for each AF. My point is the ISIS way and multiple instance ids are far more equivalent than your proposal. The only commonality between your proposal and ISIS is saving on formation of adjacencies. > > ->The only saving is in the adjacency formation. > > You save also in maintaining LSDB multiple times, further saving in > adjacency leads to saving of flooding LSDB multiple times ( once for > each AF ) and decrease in packet processing Not in ISIS. Yes, with your proposal but not siginificantly. Quaizar > > ->The changes you are proposing in the draft are changes to the > ->protocol itself and are not a generic or a single high level > ->change which fixes everything in a clean and complete way. > ->The fear is in the unknown, i.e. further bandages which will > ->be needed. > > The way OSPFv3 was defined, it allows to separate topology information > from prefix information, further prefix LSA information are defined in a > flexible way which could be used for other AF > > Therefore the proposed draft leverage and optimize the current OSPFv3 > allowing to integrate different AF within OSPFv3, the addition is 2 new > LSAs which are generic to all AF and not a big deal. > > I would like to ask WG to debate if they want to go with an integrated > approach or SIN, as OSPFv3 is in the initial deployment phase and a > decision need to be made. > > Sina
- Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Vivek Dubey
- Re: Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Quaizar Vohra
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Quaizar Vohra
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Russ White
- Re: Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Quaizar Vohra
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 dhaval gada
- Re: Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Quaizar Vohra
- Re: Address Family Support in OSPFv3 Russ White
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Quaizar Vohra
- Re: Address Family Support in OSPFv3 Quaizar Vohra
- Re: Address Family Support in OSPFv3 Acee Lindem
- Re: Address Family Support in OSPFv3 Sina Mirtorabi
- Re: Address Family Support in OSPFv3 Sina Mirtorabi