From ospf-bounces@ietf.org Wed Apr 05 19:11:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHA5-00088e-D7; Wed, 05 Apr 2006 19:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHA4-00088Z-LV for ospf@ietf.org; Wed, 05 Apr 2006 19:11:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHA4-0002FI-3F for ospf@ietf.org; Wed, 05 Apr 2006 19:11:40 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2006 19:11:40 -0400 X-IronPort-AV: i="4.04,91,1144036800"; d="txt'?scan'208"; a="85824869:sNHT47042652" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k35NBdVU015241 for ; Wed, 5 Apr 2006 19:11:39 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 19:11:39 -0400 Received: from [10.82.225.3] ([10.82.225.3]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 19:11:38 -0400 Message-ID: <44344EAA.6090005@cisco.com> Date: Wed, 05 Apr 2006 19:11:38 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OSPF List Content-Type: multipart/mixed; boundary="------------080104020500070103070101" X-OriginalArrivalTime: 05 Apr 2006 23:11:39.0036 (UTC) FILETIME=[4B0B85C0:01C65906] X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Subject: [OSPF] IETF 65 OSPF WG Meeting Minutes X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --------------080104020500070103070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks much to Michael Barnes for taking minutes and capturing the extended discussion during the OSPF MANET presentations. If you feel you were misquoted, please send corrections to me. Thanks, Acee --------------080104020500070103070101 Content-Type: text/plain; name="IETF65-ospf-wg-minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IETF65-ospf-wg-minutes.txt" IETF65 OSPF WG minutes March 23, 2006 Dallas, TX Scribe: Michael Barnes (mjbarnes@cisco.com) 09:00 CST Administriva ------------ 09:04 Review Agenda Document Status --------------- 09:05 Editor's Queue Waiting IESG Finished - Waiting on Activities Request to know who is implementing MTR Request to know who is implementing TE for OSPFv3 * Bill Fenner - OSPFv3 Auth has entered the editor's queue * Acee - I know of at least 3 implementations Will do last call for "Advertising a Router's Local Addresses in OSPF TE Extensions" Not add optimizations for "OSPF for IPv6" respin. Keep it as is. OSPFv3 Graceful Restart going to last call. Soon to be two implimenations. Waiting on two implementations for "OSPF Multi-Area Adjacency". Was experimental, but going to make it standards track. More work going on MIB for OSPFv3 Have seen customer need for "Extensions to OSPFv2 for Advertising Optional Router/Link Attributes" Will consider taking "OSPF Link-Local Signaling" to standards track Immediate Reply Hello --------------------- 09:16 Presented by Xiaoyi Guo (not Zengjie, as in the agenda) Questions * Acee - Do we want to make a document for this? Because a lot of implementations just do this. Most routers just send a hello when the interface first come up. For neighbor state changes, is only if BDR flaps, most routers send hello immediately when they come up, so what's the advantage? Don't see an advantage of sending a hello when DR role changes * Xiaoyi - Advantage is the then the DR can quickly become the BDR * Acee - but most routers send the hello anyway when they first come up * Acee - take to list * Acee - regarding the part of going straight to 2way state, also some routers do this already. * Mike Shand - The issue of whether we want to standardize is whether it affects interoperability. It doesn't seem to, so there is no apparent reason to standardize this behavior. * Padma Pillay-Esnault - Same comment as Mike. Implementation detail. If using BFD will cover cases where interfaces are flapping. Most implementations send hello when they come up. Question numbers shown in the slides. Those numbers depend on implementation and would probably not be accurate for many real implementations. * Acee - How many people think it's a good idea to document? Mixed, little bit more for not. Acee - More discussion on the list. OSPF MPR Extension - Emmanuel Baccelli ------------------ 09:30 Emmanuel Baccelli * Tom Henderson - Wondering if you will make available the simulation models? * Emmanuel - Sure * Tom - Can you describe the simulations? * Emmanuel - These are canonical(?) results * Acee - more time for discussions after all of the MANET presentations * Acee - Note that point of this draft is that routers use the shortest path to make adj decision. OSPF MDR Draft Update - Tom Henderson for Richard Ogier --------------------- 09:43 Tom Henderson Background information can be found in the mailing list archives. * Philippe Jacquet - (was link quality considered for selection?) * Tom - Not looked at link quality to date * Philippe - * Tom - My understanding of the test, are not considering link quality in the selection process * Philippe - (think link quality is something which should be considered) * Tom - When selecting MDR must consider multiple factors, but don't think it's been studied * Acee - Hesitant to get into link quality game because of differences between radios. Difficult to standardize across radios. * Tom - I think it is important to consider whether or not (to use link quality) * Philippe - Using link quality is a difficult problem * Philippe - In your simulation do you use link quality when compute the cost? * Tom - I think the point (Philippe) made is at every hop there is a SPF computation, from the perspective of the first node, and hence the cost, is different because the links used in it's SPF are different from the downstream links? * Philippe - yes * Tom - have not looked at the difference. Have looked at paths that are selected using full topologies compared to path links using overlapping relay and MDR case. But not at case described by new draft. OSPF MDR Position - Tom Henderson for Richard Ogier ----------------- 09:55 Tom Henderson (slide 5) * Joe Macker - Question: Richard described k hop case, would be good to show the algorithm is generalized, but really probably going to implement the 2 hop case * Tom - The parameter is among this set of neighbors, not tuning the number of hops * Joe - Assuming, pretty much looking at 2 hop neighbor algorithm * Acee - Even if looking at 2 hop neighborhood, could still have k greater than 2 * Philippe - What is the purpose of this selection rule? (backup MDR) * Tom - What is the purpose of having backup MDRs period? The purpose is to have redundancy in the MDR set. Say if the primary were to fail, the backup would be sufficient. * Acee - Gives you a disjoint flooding set from your two hop neighbors (slide 6) * Emmanuel - When have MDR and BMDR set, similar to case where regular network, have property where both are sync? * Tom - No, no guarantee that any two nodes which are sync with same MDR have same BMDR (slide 8) * Acee - Note: usually stretch factor refers to data plane, but in this slide refers to flooding plane (slide 9) * Philippe - MDR may not be optimal for all scenarios. MPR may be a better compromise for more scenarios. * Tom - There are a lot of options, we have not fully explored all options in simulations, we have covered a lot of them. We have seen better performance from reducing the number of adjacencies the most. We have looked at a subset of the parameters, the ones they feel are more important. We feel the capability to drop the number of adjacencies significantly is the best. Some of the properties that MPR talks about, like providing the shortest path, may result in updating the flooding set much more often to maintain those properties. Trying to maintain some properties looses others, it's a complicated tradeoff. You have a higher rate of change when trying to keep the properties that Emmanuel describes. * Padma - I don't see how it is valid to come to these numbers without doing simulations using MPR (new draft) * Tom - There are statistics you can look at just using OR simulations * Padma - I think these are not real numbers, simulations are not like the real thing. * Tom - This draft only published a few weeks ago so there was no time for all those simulations * Padma - I think we should not be doing comparisons unless we have them * Tom - MDR and OR have been on the table for long time. Emmanuel's draft was only out in last month, so there was no time to compare with that. But other models have been around for long time and comparisons for these simulations are good * Acee - GTNetS simulation code is available to anyone, so anybody can take their ideas and do their simulations * Joe - I have the same idea as Padma, but not as strongly. Studies are good, I have been involved with simulations. But it's not so clear to me regarding the tradeoff of MPR. Somewhat it depends on the heuristics used, you can change the amount of rate of adjacency change. I'm hesitant to jump to conclusion of the last two bullets on this slide. * Tom - I'm reporting Richards claims. We have done ourselves looking at OR spec, to do modeling. But not done a model the way Emmanuel has (described in his draft). * Emmanuel - Regarding adjacency reduction, (I think there is) confusion. There is a difference between adjacency reduction and topology reduction. These are different matters. One decreases the number of packets verses the size of LSAs and the size of LSUpdates. This hasn't been clear in the debate. * Tom - Agree that there are two components. Looked at combining different aspects, combinations. If you're saying that in MDR case they are the same, I disagree. MPR is analogous to a mode in Richard's testing advertising only adjacencies. * Acee - point advertising 2way is one thing that SP uses that concept to decouple flooding path from route computation. Not a new idea or unique to Richard's proposal. * Tom - Conclusion, Richard proposes that WG move forward with MDR based design. OSPF MANET DT Progress/Next Step - Tom Henderson -------------------------------- 10:28 Tom Henderson * Joe - Clarification, I was looking at SP type of approach. Richard has come up with way to look at MRP-CDS. I don't see it as off the table. For the standard, we might want to pick one. But it is not clear to me, they have similar benefits, adjacency formation one is better. Flooding options are about the same. Kind of interested in going forward with MDR but want to consider MPR-CDS. * Tom - Would like to build out further (in simulation) Emmanuel's proposal and see if MPR-CDS could apply to that. We can, in parallel, have a draft that would take OR/SP off the table, and a new draft based on MPR. * Joe - It would be good to get past this issue. * Emmanuel - Regarding Joe's comment re: MPR having more adjacency changes: once (it is) decided that LSAs advertise links that are not adjacent, then saying that MPR has more adjacency changes is not correct, it depends on the scheme. I want to point out that we have to be clear on constraints being looking at. * Acee - I think with your approach you could get further if you take into consideration if you already have an adjacency. Should make the assumption that advertising 2way is okay, if they meet other criteria, covered by CDS. * Emmanuel - then if this is a constraint we give up, then claim that MPR has a higher rate of new adjacencies is wrong. * Tom - What I've seen is that MPR does create more adjacencies because of source specific nature. Rate is affected by other elements such as adding permanence for selecting MDR, neighbor quality, etc * Emmanuel - Don't understanding if you use MDR how get more adjacencies * Tom - Need something in the algorithm to make sure the adjacency set remains connected. MDR gives you essentially a backbone that stays connected. If use another approach, what is it? * Emmanuel - Decouple adjacency, what is advertised, from flooding. So it is wrong to just talk about adjacency rate. * Acee - Can not decouple the adjacency path from flooding path, because we took it as a constraint that OSPF has reliable flooding, and retransmit along adjacencies. * Philippe - Are you sure that by advertising LSA, it is not going to create much more traffic then created with new adjacencies? * Tom - If you advertise fuller LSAs then it must increase flooding because higher frequency of updates. * Philippe - * Tom - We've able to isolate different comp, diff adjacency strategies with different topology strategies. One study is looking at full adjacencies to partial adjacencies, could be done with topology too. There is a benefit to reducing topology in LSAs because adding more neighbors increases frequency when LSAs are updated. * Acee - Let's keep as future work * Joe - Historically, when design started, we decided to have non-goal to overoptimize the protocol. When we get to point where it is close, then probably should stop. 1% improvement not worth to add complexity. Fitting into the OSPF framework, is still a goal. * Acee - agree. * Bill Fenner - have a lot of experience with spinning when have multi protocols that do the same thing. If that's what we're doing, then find a way to break the loop. Encourage everyone to break the loop themselves. * Acee - When kept on looking at simulation results, from that env, it's obvious that the MDR solution with bi-directed subgraph intuitively has better result. Regarding complexity, we need more people to work on optimizing the algorithm. I would disagree with Richard that it is simple. but remember back in 1991 that folks thought that basic SPF was complicated. Now this is not true. Same thing with disjoint path algorithm. (Folks should) spend the time (studying the algorithm) to get an intuitive feel for it. Just picking a subset of people to flood with. Move forward with this, also evaluate the MPR proposal. Another option, open up like at beginning of MANET, allow a number of proposals - but I doubt we'd ever converge. * Thomas - agree with Acee. Will say that I hope that folks take the spirit of adding something rather than throwing a monkey wrench into the process. * Acee - Trouble reaching consensus. Apologies to folks who were surprised. Not a WG consensus, just among others on some of the draft. Just a rough consensus. Encourage putting MPR draft into simulation to see how it fares. OSPF WG Charter - Acee ---------------------- 10:51 Lot of things being worked on which are not on the charter. * Tom - MANET topology reduction on charter? OSPF WG Charter Discussion -------------------------- * Kiretti Kompella - question on TE * Acee - will last call that * Kiretti - not talking about as new charter item, but talking to Dmitri, merge drafts. * Acee - if we do ASON, that is big enough, would be charter item. * Kiretti - ASON just put in /32 vs /128s, could make single TLV. Fact can be used by ASON is orthogonal. Political issues on whether to merge or not. * Acee - Call TE node prefix. 11:00 meeting adjourned. --------------080104020500070103070101 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --------------080104020500070103070101-- From ospf-bounces@ietf.org Fri Apr 07 18:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRz5u-0004uP-3D; Fri, 07 Apr 2006 18:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRz5s-0004uK-Ur for ospf@ietf.org; Fri, 07 Apr 2006 18:06:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRz5p-00087I-6Q for ospf@ietf.org; Fri, 07 Apr 2006 18:06:16 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2006 15:06:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,98,1144047600"; d="txt'?scan'208"; a="25452360:sNHT36444980" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k37M65VY024212 for ; Fri, 7 Apr 2006 18:06:12 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 18:06:06 -0400 Received: from [10.82.240.36] ([10.82.240.36]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 18:06:06 -0400 Message-ID: <4436E24D.4080507@cisco.com> Date: Fri, 07 Apr 2006 18:06:05 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OSPF List Content-Type: multipart/mixed; boundary="------------000008010609070106090004" X-OriginalArrivalTime: 07 Apr 2006 22:06:06.0416 (UTC) FILETIME=[77D8D500:01C65A8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Subject: [OSPF] Updated Minutes from IETF 65 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --------------000008010609070106090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See updated minutes attached. Thanks, Acee --------------000008010609070106090004 Content-Type: text/plain; name="IETF65-ospf-wg-minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IETF65-ospf-wg-minutes.txt" IETF65 OSPF WG minutes March 23, 2006 Dallas, TX Scribe: Michael Barnes (mjbarnes@cisco.com) 09:00 CST Administriva ------------ 09:04 Review Agenda Document Status --------------- 09:05 Editor's Queue Waiting IESG Finished - Waiting on Activities Request to know who is implementing MTR Request to know who is implementing TE for OSPFv3 * Bill Fenner - OSPFv3 Auth has entered the editor's queue * Acee - I know of at least 3 implementations Will do last call for "Advertising a Router's Local Addresses in OSPF TE Extensions" Not add optimizations for "OSPF for IPv6" respin. Keep it as is. OSPFv3 Graceful Restart going to last call. Soon to be two implimenations. Waiting on two implementations for "OSPF Multi-Area Adjacency". Was experimental, but going to make it standards track. More work going on MIB for OSPFv3 Have seen customer need for "Extensions to OSPFv2 for Advertising Optional Router/Link Attributes" Will consider taking "OSPF Link-Local Signaling" to standards track Immediate Reply Hello --------------------- 09:16 Presented by Xiaoyi Guo (not Zengjie, as in the agenda) Questions * Acee - Do we want to make a document for this? Because a lot of implementations just do this. Most routers just send a hello when the interface first come up. For neighbor state changes, is only if BDR flaps, most routers send hello immediately when they come up, so what's the advantage? Don't see an advantage of sending a hello when DR role changes * Xiaoyi - Advantage is the then the DR can quickly become the BDR * Acee - but most routers send the hello anyway when they first come up * Acee - take to list * Acee - regarding the part of going straight to 2way state, also some routers do this already. * Mike Shand - The issue of whether we want to standardize is whether it affects interoperability. It doesn't seem to, so there is no apparent reason to standardize this behavior. * Padma Pillay-Esnault - Same comment as Mike. Implementation detail. If using BFD will cover cases where interfaces are flapping. Most implementations send hello when they come up. Question numbers shown in the slides. Those numbers depend on implementation and would probably not be accurate for many real implementations. * Acee - How many people think it's a good idea to document? Mixed, little bit more for not. Acee - More discussion on the list. OSPF MPR Extension - Emmanuel Baccelli ------------------ 09:30 Emmanuel Baccelli * Tom Henderson - Wondering if you will make available the simulation models? * Emmanuel - Sure * Tom - Can you describe the simulations? * Emmanuel - These are canonical(?) results * Acee - more time for discussions after all of the MANET presentations * Acee - Note that point of this draft is that routers use the shortest path to make adj decision. OSPF MDR Draft Update - Tom Henderson for Richard Ogier --------------------- 09:43 Tom Henderson Background information can be found in the mailing list archives. * Philippe Jacquet - (was link quality considered for selection?) * Tom - Not looked at link quality to date * Philippe - * Tom - My understanding of the test, are not considering link quality in the selection process * Philippe - (think link quality is something which should be considered) * Tom - When selecting MDR must consider multiple factors, but don't think it's been studied * Acee - Hesitant to get into link quality game because of differences between radios. Difficult to standardize across radios. * Tom - I think it is important to consider whether or not (to use link quality) * Philippe - Using link quality is a difficult problem * Philippe - In your simulation do you use link quality when compute the cost? * Tom - I think the point (Philippe) made is at every hop there is a SPF computation, from the perspective of the first node, and hence the cost, is different because the links used in it's SPF are different from the downstream links? * Philippe - yes * Tom - have not looked at the difference. Have looked at paths that are selected using full topologies compared to path links using overlapping relay and MDR case. But not at case described by new draft. OSPF MDR Position - Tom Henderson for Richard Ogier ----------------- 09:55 Tom Henderson (slide 5) * Joe Macker - Question: Richard described k hop case, would be good to show the algorithm is generalized, but really probably going to implement the 2 hop case * Tom - The parameter is among this set of neighbors, not tuning the number of hops * Joe - Assuming, pretty much looking at 2 hop neighbor algorithm * Acee - Even if looking at 2 hop neighborhood, could still have k greater than 2 * Philippe - What is the purpose of this selection rule? (backup MDR) * Tom - What is the purpose of having backup MDRs period? The purpose is to have redundancy in the MDR set. Say if the primary were to fail, the backup would be sufficient. * Acee - Gives you a disjoint flooding set from your two hop neighbors (slide 6) * Emmanuel - When have MDR and BMDR set, similar to case where regular network, have property where both are sync? * Tom - No, no guarantee that any two nodes which are sync with same MDR have same BMDR (slide 8) * Acee - Note: usually stretch factor refers to data plane, but in this slide refers to flooding plane (slide 9) * Philippe - MDR may not be optimal for all scenarios. MPR may be a better compromise for more scenarios. * Tom - There are a lot of options, we have not fully explored all options in simulations, we have covered a lot of them. We have seen better performance from reducing the number of adjacencies the most. We have looked at a subset of the parameters, the ones they feel are more important. We feel the capability to drop the number of adjacencies significantly is the best. Some of the properties that MPR talks about, like providing the shortest path, may result in updating the flooding set much more often to maintain those properties. Trying to maintain some properties looses others, it's a complicated tradeoff. You have a higher rate of change when trying to keep the properties that Emmanuel describes. * Padma - I don't see how it is valid to come to these numbers without doing simulations using MPR (new draft) * Tom - There are statistics you can look at just using OR simulations * Padma - I think these are not real numbers, simulations are not like the real thing. * Tom - This draft only published a few weeks ago so there was no time for all those simulations * Padma - I think we should not be doing comparisons unless we have them * Tom - MDR and OR have been on the table for long time. Emmanuel's draft was only out in last month, so there was no time to compare with that. But other models have been around for long time and comparisons for these simulations are good * Acee - GTNetS simulation code is available to anyone, so anybody can take their ideas and do their simulations * Joe - I have the same idea as Padma, but not as strongly. Studies are good, I have been involved with simulations. But it's not so clear to me regarding the tradeoff of MPR. Somewhat it depends on the heuristics used, you can change the amount of rate of adjacency change. I'm hesitant to jump to conclusion of the last two bullets on this slide. * Tom - I'm reporting Richards claims. We have done ourselves looking at OR spec, to do modeling. But not done a model the way Emmanuel has (described in his draft). * Emmanuel - Regarding adjacency reduction, (I think there is) confusion. There is a difference between adjacency reduction and topology reduction. These are different matters. One decreases the number of packets verses the size of LSAs and the size of LSUpdates. This hasn't been clear in the debate. * Tom - Agree that there are two components. Looked at combining different aspects, combinations. If you're saying that in MDR case they are the same, I disagree. MPR is analogous to a mode in Richard's testing advertising only adjacencies. * Acee - point advertising 2way is one thing that SP uses that concept to decouple flooding path from route computation. Not a new idea or unique to Richard's proposal. * Tom - Conclusion, Richard proposes that WG move forward with MDR based design. OSPF MANET DT Progress/Next Step - Tom Henderson -------------------------------- 10:28 Tom Henderson * Joe - Clarification, I was looking at SP type of approach. Richard has come up with way to look at MRP-CDS. I don't see it as off the table. For the standard, we might want to pick one. But it is not clear to me, they have similar benefits, adjacency formation one is better. Flooding options are about the same. Kind of interested in going forward with MDR but want to consider MPR-CDS. * Tom - Would like to build out further (in simulation) Emmanuel's proposal and see if MPR-CDS could apply to that. We can, in parallel, have a draft that would take OR/SP off the table, and a new draft based on MPR. * Joe - It would be good to get past this issue. * Emmanuel - Regarding Joe's comment re: MPR having more adjacency changes: once (it is) decided that LSAs advertise links that are not adjacent, then saying that MPR has more adjacency changes is not correct, it depends on the scheme. I want to point out that we have to be clear on constraints being looking at. * Acee - I think with your approach you could get further if you take into consideration if you already have an adjacency. Should make the assumption that advertising 2way is okay, if they meet other criteria, covered by CDS. * Emmanuel - then if this is a constraint we give up, then claim that MPR has a higher rate of new adjacencies is wrong. * Tom - What I've seen is that MPR does create more adjacencies because of source specific nature. Rate is affected by other elements such as adding permanence for selecting MDR, neighbor quality, etc * Emmanuel - Don't understanding if you use MDR how get more adjacencies * Tom - Need something in the algorithm to make sure the adjacency set remains connected. MDR gives you essentially a backbone that stays connected. If use another approach, what is it? * Emmanuel - Decouple adjacency, what is advertised, from flooding. So it is wrong to just talk about adjacency rate. * Acee - Can not decouple the adjacency path from flooding path, because we took it as a constraint that OSPF has reliable flooding, and retransmit along adjacencies. * Philippe - Are you sure that by advertising LSA, it is not going to create much more traffic then created with new adjacencies? * Tom - If you advertise fuller LSAs then it must increase flooding because higher frequency of updates. * Philippe - * Tom - We've able to isolate different comp, diff adjacency strategies with different topology strategies. One study is looking at full adjacencies to partial adjacencies, could be done with topology too. There is a benefit to reducing topology in LSAs because adding more neighbors increases frequency when LSAs are updated. * Acee - Let's keep as future work * Joe - Historically, when design started, we decided to have non-goal to overoptimize the protocol. When we get to point where it is close, then probably should stop. 1% improvement not worth to add complexity. Fitting into the OSPF framework, is still a goal. * Acee - agree. * Bill Fenner - have a lot of experience with spinning when have multi protocols that do the same thing. If that's what we're doing, then find a way to break the loop. Encourage everyone to break the loop themselves. * Acee - When kept on looking at simulation results, from that env, it's obvious that the MDR solution with bi-directed subgraph intuitively has better result. Regarding complexity, we need more people to work on optimizing the algorithm. I would disagree with Richard that it is simple. but remember back in 1991 that folks thought that basic SPF was complicated. Now this is not true. Same thing with disjoint path algorithm. (Folks should) spend the time (studying the algorithm) to get an intuitive feel for it. Just picking a subset of people to flood with. Move forward with this, also evaluate the MPR proposal. Another option, open up like at beginning of MANET, allow a number of proposals - but I doubt we'd ever converge. * Thomas - Our MPR I-D was not intended to be a monkey-wrench in the process but a technical contribution -- we did not know that a decision essentially had already been taken on this matter and that technical alternatives were not encouraged. * Acee - Trouble reaching consensus. Apologies to folks who were surprised. Not a WG consensus, just among others on some of the draft. Just a rough consensus. Encourage putting MPR draft into simulation to see how it fares. OSPF WG Charter - Acee ---------------------- 10:51 Lot of things being worked on which are not on the charter. * Tom - MANET topology reduction on charter? OSPF WG Charter Discussion -------------------------- * Kiretti Kompella - question on TE * Acee - will last call that * Kiretti - not talking about as new charter item, but talking to Dmitri, merge drafts. * Acee - if we do ASON, that is big enough, would be charter item. * Kiretti - ASON just put in /32 vs /128s, could make single TLV. Fact can be used by ASON is orthogonal. Political issues on whether to merge or not. * Acee - Call TE node prefix. 11:00 meeting adjourned. --------------000008010609070106090004 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --------------000008010609070106090004-- From ospf-bounces@ietf.org Sun Apr 09 18:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSirW-0005eR-NH; Sun, 09 Apr 2006 18:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSirV-0005cB-58 for ospf@ietf.org; Sun, 09 Apr 2006 18:58:29 -0400 Received: from mailz.wwp.com ([65.107.175.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSirU-0002H1-Iz for ospf@ietf.org; Sun, 09 Apr 2006 18:58:29 -0400 Received: from localhost (localhost.filter.com [127.0.0.1]) by mailz.wwp.com (Postfix) with ESMTP id D06EA5836 for ; Sun, 9 Apr 2006 15:58:24 -0700 (PDT) Received: from mailz.wwp.com ([127.0.0.1]) by localhost (mailz.wwp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18913-05 for ; Sun, 9 Apr 2006 15:58:13 -0700 (PDT) Received: from mail.wwp.com (thorondor [192.168.6.15]) by mailz.wwp.com (Postfix) with ESMTP id C614D5830 for ; Sun, 9 Apr 2006 15:58:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 9 Apr 2006 15:58:15 -0700 Message-ID: <4E9A9436C008314EAA32033B23E96FD90359C48D@thorondor.wwp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LS Updated and Ack on multi access network Thread-Index: AcZcKRV59QmDG517Rtm0YcohncsvJw== From: "Amit Grover" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Subject: [OSPF] LS Updated and Ack on multi access network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1110441893==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1110441893== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65C29.161789C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65C29.161789C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I was reading OSPF rfc 2328 and Section 13.5 and I got confused little bit. =20 If I have four routers on multi access network let's say R1-R4. R1 and R2 are DR and BDR respectively. =20 R3 and R4 will form adjacency with R1 and R2. So in R1's neighbor table there are three neighbors which are FULL (R2 R3 and R4) =20 Now R1 receives new LSA from outside and it decides to flood it on this multi access network. Since R1 knows that it is DR or network it sends the LS Update to AllSPFRouter (224.0.0.5) =20 My question is that in whose neighbor's retransmission list does it put this LS update? R2, R3 or R4? =20 Since R1 is only going to receive one ACK who will generate this ACK R2 or R3 or R4? =20 Any ideas? Thanks Amit =20 ------_=_NextPart_001_01C65C29.161789C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I was reading OSPF rfc 2328 and Section 13.5 and I = got confused little bit.

 

If I have four routers on multi access network = let’s say R1-R4. R1 and R2 are DR and BDR = respectively.

 

R3 and R4 will form adjacency with R1 and R2.  = So in R1’s neighbor table there are three neighbors which are FULL (R2 R3 and = R4)

 

Now R1 receives new LSA from outside and it decides = to flood it on this multi access network. Since R1 knows that it is DR or network = it sends the LS Update to AllSPFRouter (224.0.0.5)

 

My question is that in whose neighbor’s = retransmission list does it put this LS update? R2, R3 or = R4?

 

Since R1 is only going to receive one ACK who will = generate this ACK R2 or R3 or R4?

 

Any ideas?

Thanks

Amit

 

------_=_NextPart_001_01C65C29.161789C0-- --===============1110441893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1110441893==-- From ospf-bounces@ietf.org Sun Apr 09 21:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlDn-00013K-B8; Sun, 09 Apr 2006 21:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSlDl-00013F-D8 for ospf@ietf.org; Sun, 09 Apr 2006 21:29:37 -0400 Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSlDk-00087m-2b for ospf@ietf.org; Sun, 09 Apr 2006 21:29:37 -0400 Received: from h-68-164-82-140.snvacaid.dynamic.covad.net ([68.164.82.140] helo=earthlink.net) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FSlDh-0006zg-00; Sun, 09 Apr 2006 21:29:33 -0400 Message-ID: <44399FF4.4A60CF55@earthlink.net> Date: Sun, 09 Apr 2006 16:59:48 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Amit Grover Subject: Re: [OSPF] LS Updated and Ack on multi access network References: <4E9A9436C008314EAA32033B23E96FD90359C48D@thorondor.wwp.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Amit Grover, First, you missed that R1 needs to somehow ack that it has recieved the LSA from the outside. To verify that each nbr recieves a LSA, all nbrs that need the LSA should have the LSA placed on their retransmion list when the LSA is first sent to them. FYI: All OSPF speaking routers need a rexmit list or one that is emulated for each router. If acks are not then recived from one or more nbrs, the LSA can then be retransmited to the ones that have not acked the LSA to R1. Mitchell Erblich ----------------------- > Amit Grover wrote: > > Hi all, > > > > I was reading OSPF rfc 2328 and Section 13.5 and I got confused little > bit. > > > > If I have four routers on multi access network let’s say R1-R4. R1 and > R2 are DR and BDR respectively. > > > > R3 and R4 will form adjacency with R1 and R2. So in R1’s neighbor > table there are three neighbors which are FULL (R2 R3 and R4) > > > > Now R1 receives new LSA from outside and it decides to flood it on > this multi access network. Since R1 knows that it is DR or network it > sends the LS Update to AllSPFRouter (224.0.0.5) > > > > My question is that in whose neighbor’s retransmission list does it > put this LS update? R2, R3 or R4? > > > > Since R1 is only going to receive one ACK who will generate this ACK > R2 or R3 or R4? > > > > Any ideas? > > Thanks > > Amit > > > > --------------------------------------------------------------- > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 10 00:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnni-00005H-13; Mon, 10 Apr 2006 00:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnnh-00005C-0y for ospf@ietf.org; Mon, 10 Apr 2006 00:14:53 -0400 Received: from mailz.wwp.com ([65.107.175.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSnnf-00050E-JS for ospf@ietf.org; Mon, 10 Apr 2006 00:14:52 -0400 Received: from localhost (localhost.filter.com [127.0.0.1]) by mailz.wwp.com (Postfix) with ESMTP id 03FE15838; Sun, 9 Apr 2006 21:14:47 -0700 (PDT) Received: from mailz.wwp.com ([127.0.0.1]) by localhost (mailz.wwp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23506-01; Sun, 9 Apr 2006 21:14:36 -0700 (PDT) Received: from mail.wwp.com (thorondor [192.168.6.15]) by mailz.wwp.com (Postfix) with ESMTP id EDC7D5836; Sun, 9 Apr 2006 21:14:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] LS Updated and Ack on multi access network Date: Sun, 9 Apr 2006 21:14:37 -0700 Message-ID: <4E9A9436C008314EAA32033B23E96FD90359C496@thorondor.wwp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] LS Updated and Ack on multi access network Thread-Index: AcZcPjqgs+5YF6xdSl6rlsaEv5JORwAEt1sg From: "Amit Grover" To: "Erblichs" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org -----Original Message----- From: Erblichs [mailto:erblichs@earthlink.net]=20 Sent: Sunday, April 09, 2006 5:00 PM To: Amit Grover Cc: ospf@ietf.org Subject: Re: [OSPF] LS Updated and Ack on multi access network Amit Grover, First, you missed that R1 needs to somehow ack that it has recieved the LSA from the outside. [Amit Grover] yeah I didn't mention this explicitly but you are right. To verify that each nbr recieves a LSA, all nbrs that need the LSA should have the LSA placed on their retransmion list when the LSA is first sent to them. [Amit Grover] Hi, what I am missing here is that neighbors do not know = about this LSA until R1 sends LS Update (with DA =3D 224.0.0.5). So why = does neighbor put this LSA in their retransmission list. It's R1 who = should put this LSA in each of it's neighbor's retransmission list so = that if any of the neighbor (R2, R3, R4) doesn't ACK back then it can = retransmit this LSA only to that neighbor. Isn't it? FYI: All OSPF speaking routers need a rexmit list or one that is emulated for each router. If acks are not then recived from one or more nbrs, the LSA can then be retransmited to the ones that have not acked the LSA to R1. Mitchell Erblich ----------------------- =09 =09 =09 > Amit Grover wrote: >=20 > Hi all, >=20 >=20 >=20 > I was reading OSPF rfc 2328 and Section 13.5 and I got confused little > bit. >=20 >=20 >=20 > If I have four routers on multi access network let=92s say R1-R4. R1 = and > R2 are DR and BDR respectively. >=20 >=20 >=20 > R3 and R4 will form adjacency with R1 and R2. So in R1=92s neighbor > table there are three neighbors which are FULL (R2 R3 and R4) >=20 >=20 >=20 > Now R1 receives new LSA from outside and it decides to flood it on > this multi access network. Since R1 knows that it is DR or network it > sends the LS Update to AllSPFRouter (224.0.0.5) >=20 >=20 >=20 > My question is that in whose neighbor=92s retransmission list does it > put this LS update? R2, R3 or R4? >=20 >=20 >=20 > Since R1 is only going to receive one ACK who will generate this ACK > R2 or R3 or R4? >=20 >=20 >=20 > Any ideas? >=20 > Thanks >=20 > Amit >=20 >=20 >=20 > --------------------------------------------------------------- > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 10 00:40:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoCR-0001oi-CS; Mon, 10 Apr 2006 00:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoCQ-0001od-9z for ospf@ietf.org; Mon, 10 Apr 2006 00:40:26 -0400 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSoCP-0006JD-12 for ospf@ietf.org; Mon, 10 Apr 2006 00:40:26 -0400 Received: from h-68-164-82-140.snvacaid.dynamic.covad.net ([68.164.82.140] helo=earthlink.net) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FSoCM-0004ip-00; Mon, 10 Apr 2006 00:40:22 -0400 Message-ID: <4439C98B.3295BC98@earthlink.net> Date: Sun, 09 Apr 2006 19:57:15 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Amit Grover Subject: Re: [OSPF] LS Updated and Ack on multi access network References: <4E9A9436C008314EAA32033B23E96FD90359C496@thorondor.wwp.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Inline.. Mitchell Erblich Amit Grover wrote: > > -----Original Message----- > From: Erblichs [mailto:erblichs@earthlink.net] > Sent: Sunday, April 09, 2006 5:00 PM > To: Amit Grover > Cc: ospf@ietf.org > Subject: Re: [OSPF] LS Updated and Ack on multi access network > > Amit Grover, > > First, you missed that R1 needs to somehow ack that > it has recieved the LSA from the outside. > [Amit Grover] yeah I didn't mention this explicitly but you are right. > > To verify that each nbr recieves a LSA, all nbrs that need > the LSA should have the LSA placed on their retransmion > list when the LSA is first sent to them. > > [Amit Grover] Hi, what I am missing here is that neighbors do not know about this LSA until R1 sends LS Update (with DA = 224.0.0.5). So why does neighbor put this LSA in their retransmission list. It's R1 who should put this LSA in each of it's neighbor's retransmission list so that if any of the neighbor (R2, R3, R4) doesn't ACK back then it can retransmit this LSA only to that neighbor. Isn't it? > R1 has separate rexmit lists for each nbr (R2, R3, R4).. They reside on R1. R1 then "repeatedly" resends the LSAs to each nbr, if the nbr (R2, R3, R4) doesn't ack.. Note, some implementations CAN limit the number of rexmits to a specific nbr. This is implementation specific. ONLY if the then recieved LSA is then acked back to R1 does the Nbr (R2, R3, R4) then decide whether it will forward the LSA. If it decides that it will then forward the LSA, does it then place the LSA again on its nbr's rexmit lists and is then sent. This process repeats based on the LSA type and the flooding scope of the LSA. > FYI: All OSPF speaking routers need a rexmit list or one > that is emulated for each router. > > If acks are not then recived from one or more nbrs, the LSA can > then be retransmited to the ones that have not acked the LSA > to R1. > > Mitchell Erblich > ----------------------- > > > > > > > > Amit Grover wrote: > > > > Hi all, > > > > > > > > I was reading OSPF rfc 2328 and Section 13.5 and I got confused little > > bit. > > > > > > > > If I have four routers on multi access network let’s say R1-R4. R1 and > > R2 are DR and BDR respectively. > > > > > > > > R3 and R4 will form adjacency with R1 and R2. So in R1’s neighbor > > table there are three neighbors which are FULL (R2 R3 and R4) > > > > > > > > Now R1 receives new LSA from outside and it decides to flood it on > > this multi access network. Since R1 knows that it is DR or network it > > sends the LS Update to AllSPFRouter (224.0.0.5) > > > > > > > > My question is that in whose neighbor’s retransmission list does it > > put this LS update? R2, R3 or R4? > > > > > > > > Since R1 is only going to receive one ACK who will generate this ACK > > R2 or R3 or R4? > > > > > > > > Any ideas? > > > > Thanks > > > > Amit > > > > > > > > --------------------------------------------------------------- > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 10 01:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSp85-0000fA-3Z; Mon, 10 Apr 2006 01:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSp83-0000f1-UU for ospf@ietf.org; Mon, 10 Apr 2006 01:39:59 -0400 Received: from mailz.wwp.com ([65.107.175.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSp7z-0008IE-EC for ospf@ietf.org; Mon, 10 Apr 2006 01:39:59 -0400 Received: from localhost (localhost.filter.com [127.0.0.1]) by mailz.wwp.com (Postfix) with ESMTP id 9A7C25836; Sun, 9 Apr 2006 22:39:50 -0700 (PDT) Received: from mailz.wwp.com ([127.0.0.1]) by localhost (mailz.wwp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23506-03; Sun, 9 Apr 2006 22:39:39 -0700 (PDT) Received: from mail.wwp.com (thorondor [192.168.6.15]) by mailz.wwp.com (Postfix) with ESMTP id 98E705830; Sun, 9 Apr 2006 22:39:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [OSPF] LS Updated and Ack on multi access network Date: Sun, 9 Apr 2006 22:39:41 -0700 Message-ID: <4E9A9436C008314EAA32033B23E96FD90359C498@thorondor.wwp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] LS Updated and Ack on multi access network Thread-Index: AcZcWOJagTloSR5FQRech6Zq7WooOQACBDqg From: "Amit Grover" To: "Erblichs" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Thanks, You confirmed what I was thinking. Thanks amit -----Original Message----- From: Erblichs [mailto:erblichs@earthlink.net]=20 Sent: Sunday, April 09, 2006 7:57 PM To: Amit Grover Cc: ospf@ietf.org Subject: Re: [OSPF] LS Updated and Ack on multi access network Inline.. Mitchell Erblich Amit Grover wrote: >=20 > -----Original Message----- > From: Erblichs [mailto:erblichs@earthlink.net] > Sent: Sunday, April 09, 2006 5:00 PM > To: Amit Grover > Cc: ospf@ietf.org > Subject: Re: [OSPF] LS Updated and Ack on multi access network >=20 > Amit Grover, >=20 > First, you missed that R1 needs to somehow ack that > it has recieved the LSA from the outside. > [Amit Grover] yeah I didn't mention this explicitly but you are right. >=20 > To verify that each nbr recieves a LSA, all nbrs that need > the LSA should have the LSA placed on their retransmion > list when the LSA is first sent to them. >=20 > [Amit Grover] Hi, what I am missing here is that neighbors do not = know about this LSA until R1 sends LS Update (with DA =3D 224.0.0.5). So = why does neighbor put this LSA in their retransmission list. It's R1 who = should put this LSA in each of it's neighbor's retransmission list so = that if any of the neighbor (R2, R3, R4) doesn't ACK back then it can = retransmit this LSA only to that neighbor. Isn't it? >=20 R1 has separate rexmit lists for each nbr (R2, R3, R4).. They reside on R1. R1 then "repeatedly" resends the LSAs to each nbr,=20 if the nbr (R2, R3, R4) doesn't ack.. Note, some implementations CAN limit the number of rexmits to a specific nbr. This is implementation specific. ONLY if the then recieved LSA is then acked back to R1 does the Nbr (R2, R3, R4) then decide whether it will=20 forward the LSA. If it decides that it will then forward the LSA, does it then place the LSA again on its nbr's rexmit lists and is then sent. This process repeats based on the LSA type and the flooding scope of the LSA. =09 > FYI: All OSPF speaking routers need a rexmit list or one > that is emulated for each router. >=20 > If acks are not then recived from one or more nbrs, the LSA = can > then be retransmited to the ones that have not acked the LSA > to R1. >=20 > Mitchell Erblich > ----------------------- >=20 >=20 >=20 >=20 >=20 >=20 > > Amit Grover wrote: > > > > Hi all, > > > > > > > > I was reading OSPF rfc 2328 and Section 13.5 and I got confused = little > > bit. > > > > > > > > If I have four routers on multi access network let=92s say R1-R4. R1 = and > > R2 are DR and BDR respectively. > > > > > > > > R3 and R4 will form adjacency with R1 and R2. So in R1=92s neighbor > > table there are three neighbors which are FULL (R2 R3 and R4) > > > > > > > > Now R1 receives new LSA from outside and it decides to flood it on > > this multi access network. Since R1 knows that it is DR or network = it > > sends the LS Update to AllSPFRouter (224.0.0.5) > > > > > > > > My question is that in whose neighbor=92s retransmission list does = it > > put this LS update? R2, R3 or R4? > > > > > > > > Since R1 is only going to receive one ACK who will generate this ACK > > R2 or R3 or R4? > > > > > > > > Any ideas? > > > > Thanks > > > > Amit > > > > > > > > --------------------------------------------------------------- > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Apr 14 18:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWZ5-00047J-Lv; Fri, 14 Apr 2006 18:14:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWZ4-00047E-UQ for ospf@ietf.org; Fri, 14 Apr 2006 18:14:54 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUWZ3-0002a3-CC for ospf@ietf.org; Fri, 14 Apr 2006 18:14:54 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FUWZP-0003lS-00 for ospf@ietf.org; Fri, 14 Apr 2006 23:15:15 +0100 Received: from Puppy ([217.158.132.56] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 23:15:25 +0100 Message-ID: <15a101c66010$e75e2d90$bf849ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 14 Apr 2006 23:14:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 Apr 2006 22:15:26.0437 (UTC) FILETIME=[EE898150:01C66010] X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Tomohiro Otani , "Thomas D. Nadeau" , ccamp@ops.ietf.org Subject: [OSPF] New OSPF MIB module for TE and GMPLS X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, As originators of the GMPLS extensions for OSPF (RFC4203) the CCAMP working group has a responsibility to develop a MIB module for the management and modelling of these extensions. At the same time, we observed that there is currently no MIB module for the TE extensions described in RFC3630. We have started a work item in draft-ietf-ccamp-gmpls-ospf-mib-00.txt to provide this support and we would welcome ongoing review and input from the OSPF working group. Comments on the CCAMP mailing list or direct to the authors or chairs. If there is a strong feeling that the work should be in the OSPF working group we are open to negotiation. In particular, I notice that draft-ietf-ospf-mib-update-10.txt is still in progress, Thanks, Adrian _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 17 11:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVad-0002tL-I7; Mon, 17 Apr 2006 11:24:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVab-0002tG-Vb for ospf@ietf.org; Mon, 17 Apr 2006 11:24:33 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVaa-0003h9-Mp for ospf@ietf.org; Mon, 17 Apr 2006 11:24:33 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 17 Apr 2006 08:24:34 -0700 X-IronPort-AV: i="4.04,125,1144047600"; d="scan'208"; a="424094392:sNHT27499048" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3HFOUw7006630 for ; Mon, 17 Apr 2006 08:24:32 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 11:24:31 -0400 Received: from [10.82.208.175] ([10.82.208.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 11:24:30 -0400 Message-ID: <4443B32E.7050501@cisco.com> Date: Mon, 17 Apr 2006 11:24:30 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2006 15:24:30.0975 (UTC) FILETIME=[05F9D0F0:01C66233] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [OSPF] OSPFv3 Graceful Restart - draft-ietf-ospf-ospfv3-graceful-restart-03.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org As I indicated at the list OSPF WG meeting in Dallas, there are 2 implementations of this document and we plan to WG last call it. Hence, without further ado, this is start of the WG Last Call for OSPFv3 Graceful Restart. All comments should be received prior to 12:00 AM (EDT), May 2nd, 2006. Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Apr 19 03:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW6n0-0003Da-Pq; Wed, 19 Apr 2006 03:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW6mz-0003DV-QG for ospf@ietf.org; Wed, 19 Apr 2006 03:07:49 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FW6mw-0002QR-RV for ospf@ietf.org; Wed, 19 Apr 2006 03:07:49 -0400 Received: (qmail 18318 invoked by uid 510); 19 Apr 2006 07:06:50 -0000 Date: 19 Apr 2006 07:06:49 -0000 Message-ID: <20060419070649.18310.qmail@webmail36.rediffmail.com> Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 19 apr 2006 07:06:49 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: "OSPF List" X-Spam-Score: 1.3 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [OSPF] Ospfv2-Multiple Interfaces Same subnet X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075852001==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============0075852001== Content-type: multipart/alternative; boundary="Next_1145430409---0-203.199.83.248-18289" This is a multipart mime message --Next_1145430409---0-203.199.83.248-18289 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Reposting for views. How open is WG to usage of "ospfNbrAddressLessIndex" M= IB object as differentiator (when NBR IP is same) to represent the neighbor= on each of the interface.=0A=0A=0AOn Fri, 24 Mar 2006 Vivek Dubey wrote := =0A>Broadcast Interfaces (Multiple interfaces in the same subnet):=0A>Route= r R1:=0A>----------=0A>Interfaces: I11(198.10.10.1/24) and I12(198.10.10.2/= 24)=0A>=0A>Router R2:=0A>----------=0A>Interface I21(198.10.10.3/24)=0A>=0A= >At R1 two NBR FSM's can be run for NBR IP:198.10.10.3 (i.e R2) as per=0A>R= FC 2328 Appendix F(one possible solution).=0A>=0A>Wondering which of the tw= o NBR FSM(s) would be used to represent "OSPF Neighbor Table" of the standa= rd OSPFv2 MIB.=0A>=0A>Looks like "ospfNbrAddressLessIndex" defined in MIB w= ould be of help=0A>but its definition as of now dont allow its usage.=0A>= =0A>Any thoughts?=0A>=0A>-Vivek=0A --Next_1145430409---0-203.199.83.248-18289 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AReposting for views. How open is WG to usage of "ospfNbrAddressL= essIndex" MIB object as differentiator (when NBR IP is same) to repres= ent the neighbor on each of the interface.
=0A
=0A
=0AOn Fri, 24 M= ar 2006 Vivek Dubey wrote :
=0A>Broadcast Interfaces (Multiple interf= aces in the same subnet):
=0A>Router R1:
=0A>----------
=0A&= gt;Interfaces: I11(198.10.10.1/24) and I12(198.10.10.2/24)
=0A>
= =0A>Router R2:
=0A>----------
=0A>Interface I21(198.10.10.3/= 24)
=0A>
=0A>At R1 two NBR FSM's can be run for NBR IP:198.10.1= 0.3 (i.e R2) as per
=0A>RFC 2328 Appendix F(one possible solution).=0A>
=0A>Wondering which of the two NBR FSM(s) would be used to = represent "OSPF Neighbor Table" of the standard OSPFv2 MIB.
= =0A>
=0A>Looks like "ospfNbrAddressLessIndex" defined in= MIB would be of help
=0A>but its definition as of now dont allow its= usage.
=0A>
=0A>Any thoughts?
=0A>
=0A>-Vivek
= =0A=0A

=0A

=0A=0A --Next_1145430409---0-203.199.83.248-18289-- --===============0075852001== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0075852001==-- From ospf-bounces@ietf.org Wed Apr 19 03:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW7ZS-0007xg-DG; Wed, 19 Apr 2006 03:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW7ZR-0007xb-Uh for ospf@ietf.org; Wed, 19 Apr 2006 03:57:53 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FW7ZQ-0004Z7-44 for ospf@ietf.org; Wed, 19 Apr 2006 03:57:53 -0400 Received: (qmail 28761 invoked by uid 510); 19 Apr 2006 07:56:56 -0000 Date: 19 Apr 2006 07:56:56 -0000 Message-ID: <20060419075656.28760.qmail@webmail36.rediffmail.com> Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 19 apr 2006 07:56:56 -0000 MIME-Version: 1.0 From: "Vivek Dubey" To: "OSPF List" X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [OSPF] Ospfv3 Options X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vivek Dubey List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1453310534==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============1453310534== Content-type: multipart/alternative; boundary="Next_1145433416---0-203.199.83.248-28676" This is a multipart mime message --Next_1145433416---0-203.199.83.248-28676 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline draft-ietf-ospf-ospfv3-update-08:=0AA.2 The Options field - V6 bit and R-b= it=0A=0AHow does Ospf for Ipv6 decides whether to "set/clear" these bits in= Options advertised. Are they part of configuration? =0AOr "draft-ietf-ospf= -cap-08.txt" could be used to advertise these capabilities.=0A=0AThanks=0AV= ivek=0A=0A =0A=0A=0A=0A=0A=0A --Next_1145433416---0-203.199.83.248-28676 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0Adraft-ietf-ospf-ospfv3-update-08:
=0AA.2  The Options field -= V6 bit and R-bit
=0A
=0AHow does Ospf for Ipv6 decides whether to &q= uot;set/clear" these bits in Options advertised. Are they part of conf= iguration?
=0AOr "draft-ietf-ospf-cap-08.txt" could be used t= o advertise these capabilities.
=0A
=0AThanks
=0AVivek
=0A
= =0A
=0A
=0A
=0A
=0A
=0A
=0A=0A

=0A

=0A=0A --Next_1145433416---0-203.199.83.248-28676-- --===============1453310534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1453310534==-- From ospf-bounces@ietf.org Wed Apr 19 05:46:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW9G4-00071t-81; Wed, 19 Apr 2006 05:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW9G2-00071o-Si for ospf@ietf.org; Wed, 19 Apr 2006 05:45:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW9G1-0000cR-Kg for ospf@ietf.org; Wed, 19 Apr 2006 05:45:58 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Apr 2006 02:45:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,133,1144047600"; d="scan'208"; a="26180497:sNHT23000568" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3J9jvTL017745; Wed, 19 Apr 2006 05:45:57 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 05:45:57 -0400 Received: from [10.82.208.175] ([10.82.208.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 05:45:56 -0400 Message-ID: <444606D1.1040405@cisco.com> Date: Wed, 19 Apr 2006 05:45:53 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Dubey Subject: Re: [OSPF] Ospfv3 Options References: <20060419075656.28760.qmail@webmail36.rediffmail.com> In-Reply-To: <20060419075656.28760.qmail@webmail36.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2006 09:45:56.0799 (UTC) FILETIME=[0E9C0CF0:01C66396] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Vivek, Vivek Dubey wrote: >draft-ietf-ospf-ospfv3-update-08: >A.2 The Options field - V6 bit and R-bit > >How does Ospf for Ipv6 decides whether to "set/clear" these bits in Options advertised. Are they part of configuration? > > The R bit allows a router to be reachable via it's stub networks without being used for transit traffic. I would expect this to be a configuration option for multi-homed hosts. It also could be set in situations where the router is running BGP and it has not yet converged (ala, RFC 3137). The V6 bit was an attempt at supporting multiple address families in OSPFv3. However, more protocol constructs than this bit are needed. You can reference the drafts we are currently considering for support of multiple topologies/address families. >Or "draft-ietf-ospf-cap-08.txt" could be used to advertise these capabilities. > > This draft wouldn't be applicable here. It is for optional OSPFv2/OSPFv3 capabilities. Hope this helps, Acee >Thanks >Vivek > > > > > > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Apr 19 15:42:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWIZ0-0000U5-3Y; Wed, 19 Apr 2006 15:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWIYy-0000U0-9y for ospf@ietf.org; Wed, 19 Apr 2006 15:42:08 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWIYy-0002wJ-0f for ospf@ietf.org; Wed, 19 Apr 2006 15:42:08 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Apr 2006 12:42:08 -0700 X-IronPort-AV: i="4.04,136,1144047600"; d="scan'208"; a="1796662315:sNHT33252144" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3JJfwVo020341; Wed, 19 Apr 2006 12:42:07 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 15:42:04 -0400 Received: from [10.82.208.175] ([10.82.208.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 15:42:04 -0400 Message-ID: <4446928B.6030402@cisco.com> Date: Wed, 19 Apr 2006 15:42:03 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Dubey Subject: Re: [OSPF] Ospfv2-Multiple Interfaces Same subnet References: <20060419070649.18310.qmail@webmail36.rediffmail.com> In-Reply-To: <20060419070649.18310.qmail@webmail36.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2006 19:42:04.0135 (UTC) FILETIME=[559A6770:01C663E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Vivek Dubey wrote: >Reposting for views. How open is WG to usage of "ospfNbrAddressLessIndex" MIB object as differentiator (when NBR IP is same) to represent the neighbor on each of the interface. > > Hi Vivek, Do you actually have an implementation that allows this or is it a hypothetical question? Anyway, since the technique is documented in an appendix and there are multiple options, I'd prefer we don't try and solve the problem in the OSPF WG. As for your suggestion, it appears to me that it would be compatible but you may confuse programs that query the MIB. Thanks, Acee > >On Fri, 24 Mar 2006 Vivek Dubey wrote : > > >>Broadcast Interfaces (Multiple interfaces in the same subnet): >>Router R1: >>---------- >>Interfaces: I11(198.10.10.1/24) and I12(198.10.10.2/24) >> >>Router R2: >>---------- >>Interface I21(198.10.10.3/24) >> >>At R1 two NBR FSM's can be run for NBR IP:198.10.10.3 (i.e R2) as per >>RFC 2328 Appendix F(one possible solution). >> >>Wondering which of the two NBR FSM(s) would be used to represent "OSPF Neighbor Table" of the standard OSPFv2 MIB. >> >>Looks like "ospfNbrAddressLessIndex" defined in MIB would be of help >>but its definition as of now dont allow its usage. >> >>Any thoughts? >> >>-Vivek >> >> > > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Apr 20 05:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWVuO-0001QO-Kx; Thu, 20 Apr 2006 05:57:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWVuN-0001QJ-LD for ospf@ietf.org; Thu, 20 Apr 2006 05:57:07 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWVuN-0004yO-7m for ospf@ietf.org; Thu, 20 Apr 2006 05:57:07 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k3KAIJZP020280 for ; Thu, 20 Apr 2006 03:18:19 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3KA8gUN024056 for ; Thu, 20 Apr 2006 05:08:43 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Apr 2006 17:53:20 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DR Election - NeighborChange event Thread-Index: AcZkYEGE/Ez976BUQdiJE1blFj9wOQ== From: "Ramana Koppula-G20085" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [OSPF] DR Election - NeighborChange event X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1227192355==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1227192355== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66460.C68336F4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66460.C68336F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Below are two triggers for neighborChange event which result in invocation of DR election. My doubts are given inline. =20 1) There is no longer bidirectional communication with a neighbor. In other words, the state of the neighbor has transitioned to Init or lower.[Taken from NeighborChange event description, Section 9.2 of RFC 2328] Doubt> Even if the bidirectional communication failed with a DROther router, is it required to trigger DR Election? 2) The advertised Router Priority for a bidirectional neighbor has changed. This is again detected through examination of that neighbor's Hello Packets.[Taken from NeighborChange event description, Section 9.2 of RFC 2328] Doubt> a) Is the DR Election required if the router priority of DR or BDR changed to another non-zero, which does not result in any change of the DR/BDR. thanx ramana ------_=_NextPart_001_01C66460.C68336F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Below are two triggers for neighborChange = event which=20 result in invocation of DR election. My doubts are given=20 inline.
 
1) There is no longer bidirectional = communication with=20 a neighbor. In other words, the = state of=20 the neighbor has transitioned to = Init or=20 lower.[Taken from NeighborChange=20 event description, Section 9.2 of RFC=20 2328]

Doubt> Even = if the=20 bidirectional communication failed with a DROther router, is it required = to=20 trigger DR Election?

2) The=20 advertised Router Priority for a bidirectional=20 neighbor has changed. This is again detected through examination of that neighbor’s = Hello=20 Packets.[Taken from NeighborChange=20 event description, Section 9.2 of RFC=20 2328]

Doubt> a) Is the DR Election required if the router priority = of DR or=20 BDR changed to another non-zero, which does not     = result=20 in any change of the DR/BDR.

thanx

ramana

------_=_NextPart_001_01C66460.C68336F4-- --===============1227192355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1227192355==-- From ospf-bounces@ietf.org Thu Apr 20 07:35:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWXRR-0003uA-Vb; Thu, 20 Apr 2006 07:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWXRR-0003u5-DS for OSPF@ietf.org; Thu, 20 Apr 2006 07:35:21 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWXRK-0001Wl-7Q for OSPF@ietf.org; Thu, 20 Apr 2006 07:35:21 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY0006ULRAR1B@szxga02-in.huawei.com> for OSPF@ietf.org; Thu, 20 Apr 2006 19:44:51 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY000CDERAR0A@szxga02-in.huawei.com> for OSPF@ietf.org; Thu, 20 Apr 2006 19:44:51 +0800 (CST) Received: from Rags ([10.18.4.128]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY000F8VRAGFQ@szxml02-in.huawei.com> for OSPF@ietf.org; Thu, 20 Apr 2006 19:44:40 +0800 (CST) Date: Thu, 20 Apr 2006 17:00:37 +0530 From: raghu To: OSPF@ietf.org Message-id: <010f01c6646d$d94ea2a0$8004120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [OSPF] A quibble on GR for DR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raghu@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0397975740==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============0397975740== Content-type: multipart/alternative; boundary="Boundary_(ID_RTD0jPpkiAu758A2avrYIA)" This is a multi-part message in MIME format. --Boundary_(ID_RTD0jPpkiAu758A2avrYIA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All When ever a DR is forming adjacency with Neighbors on the link after GR, Why does it have to form adjacency with all the Peers on the link. Why not only with BDR ? As BDR s Database is synchronized with each peer. Please give your opinion on this Thanks and Regards - Raghu --Boundary_(ID_RTD0jPpkiAu758A2avrYIA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All

When ever a DR is forming adjacency with Neighbors on the link after GR,

Why does it have to form adjacency with all the Peers on the link. Why not only with BDR ?

As BDR s Database is synchronized with each peer.

Please give your opinion on this

 

Thanks and Regards

- Raghu

 

--Boundary_(ID_RTD0jPpkiAu758A2avrYIA)-- --===============0397975740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0397975740==-- From ospf-bounces@ietf.org Thu Apr 20 11:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaeg-0004wu-KF; Thu, 20 Apr 2006 11:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWaef-0004wp-NK for OSPF@ietf.org; Thu, 20 Apr 2006 11:01:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWaee-0003ow-EH for OSPF@ietf.org; Thu, 20 Apr 2006 11:01:13 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 Apr 2006 08:01:10 -0700 X-IronPort-AV: i="4.04,141,1144047600"; d="scan'208"; a="270063649:sNHT29406354" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3KF0wZG023361; Thu, 20 Apr 2006 08:01:09 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 11:01:08 -0400 Received: from [10.82.208.175] ([10.82.208.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 11:01:08 -0400 Message-ID: <4447A233.4070806@cisco.com> Date: Thu, 20 Apr 2006 11:01:07 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: raghu@huawei.com Subject: Re: [OSPF] A quibble on GR for DR References: <010f01c6646d$d94ea2a0$8004120a@china.huawei.com> In-Reply-To: <010f01c6646d$d94ea2a0$8004120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2006 15:01:08.0547 (UTC) FILETIME=[414D8930:01C6648B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: OSPF@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org raghu wrote: >Hi All > >When ever a DR is forming adjacency with Neighbors on the link after GR, > > >Why does it have to form adjacency with all the Peers on the link. Why >not only with BDR ? > >As BDR s Database is synchronized with each peer. > >Please give your opinion on this > > Raghu, If you haven't established all your pre-restart adjacencies, how do you expect the new LSAs the restarting to match the pre-restart LSAs? Thanks, Acee > > >Thanks and Regards > >- Raghu > > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Apr 20 22:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWl6j-0003Bk-E8; Thu, 20 Apr 2006 22:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWl6i-0003Bf-O4 for OSPF@ietf.org; Thu, 20 Apr 2006 22:10:52 -0400 Received: from rrcs-66-91-145-219.west.biz.rr.com ([66.91.145.219] helo=apollo.adtech-inc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWl6h-0007Vt-EF for OSPF@ietf.org; Thu, 20 Apr 2006 22:10:52 -0400 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4G52F>; Thu, 20 Apr 2006 16:11:50 -1000 Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513840B@apollo.adtech-inc.com> From: "Kandula, Ramesh" To: OSPF@ietf.org Date: Thu, 20 Apr 2006 16:11:42 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [OSPF] Detecting changes in pre-restart topology (OSPF graceful restart) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi all, I have a question about OSPF graceful restart. I am wondering if someone could help me. Suppose there are two OSPF routers connected via a P2P link. One of them (RTR1) supports graceful restart and the other doesn't (RTR2). When RTR1 restarts, RTR2 detects this (from the hello's that RTR1 sends or when RTR2 receives database description packets) and updates it's router lsa (excludes the link to RTR1). From my understanding of the OSPF graceful restart RFC, the restarting router is supposed to detect this and exit restart mode. But how can it be guaranteed that the RTR1 receives this updated RTR2's lsa (i.e. the one with out the link to RTR1)? I am observing the following behavior. Of course it may depend on the implemetation but I am not completely sure. From RTR2' prespective the adjacency is established as soon as database exchange is done, since RTR1 doesn't have any link state database and thus updates it's own router lsa (by including the link to RTR1). This updated RTR2's router lsa is flooded before RTR1 requests for RTR2's router lsa during database exchange. When RTR1 looks at this new RTR2'r router lsa it doesn't see any change from pre-restart topology. thanks ramesh _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Apr 21 00:53:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWndf-0003pl-TA; Fri, 21 Apr 2006 00:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWnde-0003pa-2M for ospf@ietf.org; Fri, 21 Apr 2006 00:53:02 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWndc-0006bX-KN for ospf@ietf.org; Fri, 21 Apr 2006 00:53:02 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY20039E2TBG6@szxga01-in.huawei.com> for ospf@ietf.org; Fri, 21 Apr 2006 12:51:12 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY2007YV2TB33@szxga01-in.huawei.com> for ospf@ietf.org; Fri, 21 Apr 2006 12:51:11 +0800 (CST) Received: from [10.18.4.125] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY200HBI3MG8A@szxml01-in.huawei.com> for ospf@ietf.org; Fri, 21 Apr 2006 13:08:41 +0800 (CST) Date: Fri, 21 Apr 2006 10:20:54 +0530 From: Ashok Chandrashekar Holla Subject: Re: [OSPF] Detecting changes in pre-restart topology (OSPF graceful restart) In-reply-to: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513840B@apollo.adtech-inc.com> To: ospf@ietf.org Message-id: <444864AE.5080601@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) References: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513840B@apollo.adtech-inc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Ramesh, The issue here is one of timing and is an implementation quirk. The protocol is silent on it. The helper router can either delay the loadingDone event or send its router lsa at the earliest (prior to becoming full and adding the restarting router in its router lsa) to ensure that the restarting router learns about the non-helper behavior.This is again a best effort mechanism since there is no explicit feedback mechanism in GR. This issue can be resolved by the proposed Exit-Grace TLV in: http://www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-01.txt (Sorry for the surrogate canvasing :) ) -Ashok Kandula, Ramesh wrote: >Hi all, > >I have a question about OSPF graceful restart. I am wondering if someone >could help me. > >Suppose there are two OSPF routers connected via a P2P link. One of them >(RTR1) supports graceful restart and the other doesn't (RTR2). When RTR1 >restarts, RTR2 detects this (from the hello's that RTR1 sends or when RTR2 >receives database description packets) and updates it's router lsa (excludes >the link to RTR1). From my understanding of the OSPF graceful restart RFC, >the restarting router is supposed to detect this and exit restart mode. But >how can it be guaranteed that the RTR1 receives this updated RTR2's lsa >(i.e. the one with out the link to RTR1)? > >I am observing the following behavior. Of course it may depend on the >implemetation but I am not completely sure. From RTR2' prespective the >adjacency is established as soon as database exchange is done, since RTR1 >doesn't have any link state database and thus updates it's own router lsa >(by including the link to RTR1). This updated RTR2's router lsa is flooded >before RTR1 requests for RTR2's router lsa during database exchange. When >RTR1 looks at this new RTR2'r router lsa it doesn't see any change from >pre-restart topology. > >thanks >ramesh > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Apr 21 01:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWnnh-0002Zr-1L; Fri, 21 Apr 2006 01:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWnnf-0002Zm-LR for OSPF@ietf.org; Fri, 21 Apr 2006 01:03:23 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWnne-0007La-Ql for OSPF@ietf.org; Fri, 21 Apr 2006 01:03:23 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY200AKM3EUXP@szxga03-in.huawei.com> for OSPF@ietf.org; Fri, 21 Apr 2006 13:04:07 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY200F0U3EURQ@szxga03-in.huawei.com> for OSPF@ietf.org; Fri, 21 Apr 2006 13:04:06 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY200H2B3UX8A@szxml01-in.huawei.com>; Fri, 21 Apr 2006 13:13:46 +0800 (CST) Date: Fri, 21 Apr 2006 10:26:00 +0530 From: sujay Subject: RE: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) In-reply-to: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513840B@apollo.adtech-inc.com> To: "'Kandula, Ramesh'" , OSPF@ietf.org Message-id: <001f01c664ff$e2cafdf0$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org hi ramesh, The exit graceful restart criteria should come up well before adjacency formation. When RTR1 finds its own self generated lsa having a link to RTR2 but RTR2 has no backlink to it, it should exit GR. Further, this catch should come up during the process of building adjacency, and not after it. See section 2.2 (2) of RFC 3623. regds, sujay -----Original Message----- From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] Sent: Friday, April 21, 2006 7:42 AM To: OSPF@ietf.org Subject: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) Hi all, I have a question about OSPF graceful restart. I am wondering if someone could help me. Suppose there are two OSPF routers connected via a P2P link. One of them (RTR1) supports graceful restart and the other doesn't (RTR2). When RTR1 restarts, RTR2 detects this (from the hello's that RTR1 sends or when RTR2 receives database description packets) and updates it's router lsa (excludes the link to RTR1). From my understanding of the OSPF graceful restart RFC, the restarting router is supposed to detect this and exit restart mode. But how can it be guaranteed that the RTR1 receives this updated RTR2's lsa (i.e. the one with out the link to RTR1)? I am observing the following behavior. Of course it may depend on the implemetation but I am not completely sure. From RTR2' prespective the adjacency is established as soon as database exchange is done, since RTR1 doesn't have any link state database and thus updates it's own router lsa (by including the link to RTR1). This updated RTR2's router lsa is flooded before RTR1 requests for RTR2's router lsa during database exchange. When RTR1 looks at this new RTR2'r router lsa it doesn't see any change from pre-restart topology. thanks ramesh _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Apr 21 01:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWoVj-0004Dv-5V; Fri, 21 Apr 2006 01:48:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWoVh-0004Dq-NG for OSPF@ietf.org; Fri, 21 Apr 2006 01:48:53 -0400 Received: from rrcs-66-91-145-219.west.biz.rr.com ([66.91.145.219] helo=apollo.adtech-inc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWoVh-0000kJ-BU for OSPF@ietf.org; Fri, 21 Apr 2006 01:48:53 -0400 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4G5KC>; Thu, 20 Apr 2006 19:49:52 -1000 Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513840D@apollo.adtech-inc.com> From: "Kandula, Ramesh" To: 'sujay' , OSPF@ietf.org Subject: RE: [OSPF] Detecting changes in pre-restart topology (OSPF gracef ulrestart) Date: Thu, 20 Apr 2006 19:49:52 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Sujay Below is a sequence of packet exchange between the routers. RTR2 --> AllSpfRouters (Database Description: RTR1 router-lsa, RTR2 router-lsa (without link to RTR1), grace-lsa) RTR1 --> AllSpfRouters (Database Description: Nothing) RTR2 --> AllSpfRouters (Update: RTR2 router-lsa (with link to RTR1)) RTR1 --> AllSpfRouters (Request: RTR1 router-lsa, grace-lsa) RTR2 --> AllSpfRouters (Update: RTR1 router-lsa, grace-lsa) The point being when RTR1 never receives the RTR2's router lsa which doesn't have the link to RTR1. RTR1 recieves only the updated RTR2's router-lsa which has the link the to RTR1. So RTR1 never detects the change in topology. As Ashok mentioned, this is an implementation issue. I wonder if OSPF GR implemenations handle this correctly. thanks ramesh -----Original Message----- From: sujay [mailto:sujayg@huawei.com] Sent: Thursday, April 20, 2006 6:56 PM To: Kandula, Ramesh; OSPF@ietf.org Subject: RE: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) hi ramesh, The exit graceful restart criteria should come up well before adjacency formation. When RTR1 finds its own self generated lsa having a link to RTR2 but RTR2 has no backlink to it, it should exit GR. Further, this catch should come up during the process of building adjacency, and not after it. See section 2.2 (2) of RFC 3623. regds, sujay -----Original Message----- From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] Sent: Friday, April 21, 2006 7:42 AM To: OSPF@ietf.org Subject: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) Hi all, I have a question about OSPF graceful restart. I am wondering if someone could help me. Suppose there are two OSPF routers connected via a P2P link. One of them (RTR1) supports graceful restart and the other doesn't (RTR2). When RTR1 restarts, RTR2 detects this (from the hello's that RTR1 sends or when RTR2 receives database description packets) and updates it's router lsa (excludes the link to RTR1). From my understanding of the OSPF graceful restart RFC, the restarting router is supposed to detect this and exit restart mode. But how can it be guaranteed that the RTR1 receives this updated RTR2's lsa (i.e. the one with out the link to RTR1)? I am observing the following behavior. Of course it may depend on the implemetation but I am not completely sure. From RTR2' prespective the adjacency is established as soon as database exchange is done, since RTR1 doesn't have any link state database and thus updates it's own router lsa (by including the link to RTR1). This updated RTR2's router lsa is flooded before RTR1 requests for RTR2's router lsa during database exchange. When RTR1 looks at this new RTR2'r router lsa it doesn't see any change from pre-restart topology. thanks ramesh _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Apr 21 02:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWp4U-0007mi-Qf; Fri, 21 Apr 2006 02:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWp4S-0007md-MU for OSPF@ietf.org; Fri, 21 Apr 2006 02:24:48 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWp4J-0002VY-NA for OSPF@ietf.org; Fri, 21 Apr 2006 02:24:48 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY200D2U7JPIB@szxga02-in.huawei.com> for OSPF@ietf.org; Fri, 21 Apr 2006 14:33:26 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY200KU77JPU1@szxga02-in.huawei.com> for OSPF@ietf.org; Fri, 21 Apr 2006 14:33:25 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY200NRI7JB3T@szxml02-in.huawei.com>; Fri, 21 Apr 2006 14:33:12 +0800 (CST) Date: Fri, 21 Apr 2006 11:49:10 +0530 From: sujay Subject: RE: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) In-reply-to: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513840D@apollo.adtech-inc.com> To: "'Kandula, Ramesh'" , OSPF@ietf.org Message-id: <002a01c6650b$81394ea0$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org hi ramesh, the problem could be two fold; RTR1 is not examining the LSA's until grace period expiry . RTR2 does not send the broken lsa during the adjacency build up. the first looks like more probable, (as your packet sequence shows RTR2 is sending the broken link LSA to RTR1) as, Ashok had rightly pointed out, it looks as an implementation issue on the onset. regds, sujay -----Original Message----- From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] Sent: Friday, April 21, 2006 11:20 AM To: 'sujay'; OSPF@ietf.org Subject: RE: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) Hi Sujay Below is a sequence of packet exchange between the routers. RTR2 --> AllSpfRouters (Database Description: RTR1 router-lsa, RTR2 router-lsa (without link to RTR1), grace-lsa) RTR1 --> AllSpfRouters (Database Description: Nothing) RTR2 --> AllSpfRouters (Update: RTR2 router-lsa (with link to RTR1)) RTR1 --> AllSpfRouters (Request: RTR1 router-lsa, grace-lsa) RTR2 --> AllSpfRouters (Update: RTR1 router-lsa, grace-lsa) The point being when RTR1 never receives the RTR2's router lsa which doesn't have the link to RTR1. RTR1 recieves only the updated RTR2's router-lsa which has the link the to RTR1. So RTR1 never detects the change in topology. As Ashok mentioned, this is an implementation issue. I wonder if OSPF GR implemenations handle this correctly. thanks ramesh -----Original Message----- From: sujay [mailto:sujayg@huawei.com] Sent: Thursday, April 20, 2006 6:56 PM To: Kandula, Ramesh; OSPF@ietf.org Subject: RE: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) hi ramesh, The exit graceful restart criteria should come up well before adjacency formation. When RTR1 finds its own self generated lsa having a link to RTR2 but RTR2 has no backlink to it, it should exit GR. Further, this catch should come up during the process of building adjacency, and not after it. See section 2.2 (2) of RFC 3623. regds, sujay -----Original Message----- From: Kandula, Ramesh [mailto:Ramesh.Kandula@SpirentCom.COM] Sent: Friday, April 21, 2006 7:42 AM To: OSPF@ietf.org Subject: [OSPF] Detecting changes in pre-restart topology (OSPF gracefulrestart) Hi all, I have a question about OSPF graceful restart. I am wondering if someone could help me. Suppose there are two OSPF routers connected via a P2P link. One of them (RTR1) supports graceful restart and the other doesn't (RTR2). When RTR1 restarts, RTR2 detects this (from the hello's that RTR1 sends or when RTR2 receives database description packets) and updates it's router lsa (excludes the link to RTR1). From my understanding of the OSPF graceful restart RFC, the restarting router is supposed to detect this and exit restart mode. But how can it be guaranteed that the RTR1 receives this updated RTR2's lsa (i.e. the one with out the link to RTR1)? I am observing the following behavior. Of course it may depend on the implemetation but I am not completely sure. From RTR2' prespective the adjacency is established as soon as database exchange is done, since RTR1 doesn't have any link state database and thus updates it's own router lsa (by including the link to RTR1). This updated RTR2's router lsa is flooded before RTR1 requests for RTR2's router lsa during database exchange. When RTR1 looks at this new RTR2'r router lsa it doesn't see any change from pre-restart topology. thanks ramesh _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Apr 21 14:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0Oo-0008EV-Lf; Fri, 21 Apr 2006 14:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0On-0008EQ-C0 for ospf@ietf.org; Fri, 21 Apr 2006 14:30:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0Om-0008Ka-3x for ospf@ietf.org; Fri, 21 Apr 2006 14:30:33 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2006 11:30:31 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,146,1144047600"; d="scan'208"; a="26401835:sNHT26434132" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3LIUUvL004346; Fri, 21 Apr 2006 14:30:31 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 14:30:30 -0400 Received: from [64.102.199.99] ([64.102.199.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 14:30:29 -0400 Message-ID: <444924C5.2060209@cisco.com> Date: Fri, 21 Apr 2006 14:30:29 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel References: <15a101c66010$e75e2d90$bf849ed9@Puppy> In-Reply-To: <15a101c66010$e75e2d90$bf849ed9@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2006 18:30:29.0861 (UTC) FILETIME=[AAD7B150:01C66571] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Tomohiro Otani , "Thomas D. Nadeau" , ccamp@ops.ietf.org, ospf@ietf.org Subject: [OSPF] Re: New OSPF MIB module for TE and GMPLS X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Adrian Farrel wrote: >Hi, > >As originators of the GMPLS extensions for OSPF (RFC4203) the CCAMP >working group has a responsibility to develop a MIB module for the >management and modelling of these extensions. At the same time, we >observed that there is currently no MIB module for the TE extensions >described in RFC3630. > >We have started a work item in draft-ietf-ccamp-gmpls-ospf-mib-00.txt to >provide this support and we would welcome ongoing review and input from >the OSPF working group. Comments on the CCAMP mailing list or direct to >the authors or chairs. > >If there is a strong feeling that the work should be in the OSPF working >group we are open to negotiation. In particular, I notice that >draft-ietf-ospf-mib-update-10.txt is still in progress, > > Since we've kept the TE extensions and base OSPF separate, I'd prefer to keep the MIB drafts separate as well. With respect to draft-ietf-ospf-mib-update-10.txt, this draft has been in progress since I became OSPF WG co-chair (more than 3 years ago) and I'd prefer to progress it now that I believe we are very close to requesting publication. If we keep pulling it back and adding MIB objects for new extensions we'll never finish. I'll take a look at draft-ietf-ccamp-gmpls-ospf-mib-00.txt. Thanks, Acee >Thanks, >Adrian > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 24 07:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXzbh-0007ca-Db; Mon, 24 Apr 2006 07:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXzbg-0007bq-5I for ospf@ietf.org; Mon, 24 Apr 2006 07:51:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXxsZ-0001tk-H8 for ospf@ietf.org; Mon, 24 Apr 2006 06:01:15 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FXxm4-0001Nk-RS for ospf@ietf.org; Mon, 24 Apr 2006 05:54:35 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY8004UB1943R@szxga02-in.huawei.com> for ospf@ietf.org; Mon, 24 Apr 2006 18:03:04 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IY8002LV193P7@szxga02-in.huawei.com> for ospf@ietf.org; Mon, 24 Apr 2006 18:03:03 +0800 (CST) Received: from anup ([10.18.4.206]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IY8008P118R8K@szxml02-in.huawei.com> for ospf@ietf.org; Mon, 24 Apr 2006 18:02:51 +0800 (CST) Date: Mon, 24 Apr 2006 15:18:43 +0530 From: anup In-reply-to: <4443B32E.7050501@cisco.com> To: ospf@ietf.org Message-id: <000501c66784$4675b120$ce04120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [OSPF] OSPFv3 Graceful Restart: a query X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anupkumart@huawei.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Group, Problem: If, on a helper, an LSA reaches maxage and if the LSA was originated by a router which is currently in GR, then as per RFC 3623, the helper will flood the maxaged LSA and the other helpers receiving it will exit helper mode. Suggestion: The helper should not flush the LSA since the restarting router, during restart, cannot refresh the LSA. Instead the helper should keep the maxaged LSA in its LSDB until the restarting router is found to have exited GR, after which the restarting router will take the correct action. Kindly let me know if my understanding of the problem is right and if the suggestion is good. Thanks and Regards, Anup _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 24 10:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY1tH-0001k6-9Y; Mon, 24 Apr 2006 10:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY1tG-0001k1-Av for ospf@ietf.org; Mon, 24 Apr 2006 10:18:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY1tF-0006Dq-2N for ospf@ietf.org; Mon, 24 Apr 2006 10:18:14 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2006 07:18:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,152,1144047600"; d="scan'208"; a="26543424:sNHT7787950782" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3OEI6Tb007991; Mon, 24 Apr 2006 10:18:09 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 10:18:07 -0400 Received: from [10.21.122.110] ([10.21.122.110]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 10:18:07 -0400 Message-ID: <444CDE1C.6020204@cisco.com> Date: Mon, 24 Apr 2006 10:18:04 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: anupkumart@huawei.com Subject: Re: [OSPF] OSPFv3 Graceful Restart: a query References: <000501c66784$4675b120$ce04120a@china.huawei.com> In-Reply-To: <000501c66784$4675b120$ce04120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 14:18:07.0281 (UTC) FILETIME=[E8669A10:01C667A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org anup wrote: >Hi Group, > >Problem: > If, on a helper, an LSA reaches maxage and if the LSA was originated by >a router which is currently in GR, then as per RFC 3623, the helper will >flood the maxaged LSA and the other helpers receiving it will exit helper >mode. > >Suggestion: > The helper should not flush the LSA since the restarting router, during >restart, cannot refresh the LSA. Instead the helper should keep the maxaged >LSA in its LSDB until the restarting router is found to have exited GR, >after which the restarting router will take the correct action. > >Kindly let me know if my understanding of the problem is right and if the >suggestion is good. > > Hi Anup, I don't think what you suggest works. Even, if helpers don't flush the LSA, other routers in the domain will. And, if if they didn't, the LSA still wouldn't be used in the SPF calculation. IMHO, it is futile to try and handle this situation. If the restarting router is refreshing its self-originated LSAs every 30 minutes as per RFC 2328 then the restarting router has at least 30 minutes to restart - this should more than suffice in any practical situation. Thanks, Acee >Thanks and Regards, >Anup > > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 24 10:30:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY254-0005bn-FH; Mon, 24 Apr 2006 10:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY253-0005bi-LU for ospf@ietf.org; Mon, 24 Apr 2006 10:30:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY252-0007Ok-D9 for ospf@ietf.org; Mon, 24 Apr 2006 10:30:25 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2006 07:30:24 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,152,1144047600"; d="scan'208"; a="26545197:sNHT23421224" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3OEUOvF019316; Mon, 24 Apr 2006 10:30:24 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 10:30:23 -0400 Received: from [10.21.122.110] ([10.21.122.110]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 10:30:23 -0400 Message-ID: <444CE0FD.3030001@cisco.com> Date: Mon, 24 Apr 2006 10:30:21 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ramana Koppula-G20085 Subject: Re: [OSPF] DR Election - NeighborChange event References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 14:30:23.0418 (UTC) FILETIME=[9F2C31A0:01C667AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Ramana, Similar to the SPF calculation, if you can come up with little internal optimizations that yield the same result, you are free to implement them. In the cases below, given everything else constant, it seems that a DR election would not yield a change in DR/BDR. However, having a DR/BDR election triggered for all routers on the multi-access is arguably more robust. Also, at least one extension has been suggested that takes advantage of this property. Thanks, Acee Ramana Koppula-G20085 wrote: >Hi, > >Below are two triggers for neighborChange event which result in >invocation of DR election. My doubts are given inline. > >1) There is no longer bidirectional communication with a neighbor. In >other words, the state of the neighbor has transitioned to Init or >lower.[Taken from NeighborChange event description, Section 9.2 of RFC >2328] > >Doubt> Even if the bidirectional communication failed with a DROther >router, is it required to trigger DR Election? > >2) The advertised Router Priority for a bidirectional neighbor has >changed. This is again detected through examination of that neighbor's >Hello Packets.[Taken from NeighborChange event description, Section 9.2 >of RFC 2328] > >Doubt> a) Is the DR Election required if the router priority of DR or >BDR changed to another non-zero, which does not result in any change >of the DR/BDR. > >thanx > >ramana > > > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Apr 24 14:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY65F-0004BE-0Q; Mon, 24 Apr 2006 14:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY65D-0004Ai-B5 for ospf@ietf.org; Mon, 24 Apr 2006 14:46:51 -0400 Received: from web38302.mail.mud.yahoo.com ([209.191.125.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY65C-0003LA-Sz for ospf@ietf.org; Mon, 24 Apr 2006 14:46:51 -0400 Received: (qmail 6970 invoked by uid 60001); 24 Apr 2006 18:46:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ufxUMB+TrBfbpKzfekD12BAtFKdk/YBBs3YDmq9643EbkVnquJeFJv847qDjFcBx0vKd3HHNKOXsML2M3QWN7NbqkcOc50Fae9ZaDJbX82Y1xYDFv89HtvVhiMOE1wHiTrTeO/geyBIDnKfinBCG/+OcRiWOyhETL2Xpy9IbPUo= ; Message-ID: <20060424184650.6968.qmail@web38302.mail.mud.yahoo.com> Received: from [206.54.51.125] by web38302.mail.mud.yahoo.com via HTTP; Mon, 24 Apr 2006 11:46:50 PDT Date: Mon, 24 Apr 2006 11:46:50 -0700 (PDT) From: v punati To: ospf@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [OSPF] question about RFC 2636 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1400004487==" Errors-To: ospf-bounces@ietf.org --===============1400004487== Content-Type: multipart/alternative; boundary="0-1550345506-1145904410=:5820" Content-Transfer-Encoding: 8bit --0-1550345506-1145904410=:5820 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi , What is the significance of Vertex-id in Intra_SPF run. RFC-2328 says when the metrics are equal we should filter the route based on Vertex-id. I am attaching contents from RFC 2328 16.1 paragraph. My question is whether we can have any topologies which can run in this situation? Is this only a transit condition ? or any topology can have this one as persistant condition? Whats the problem if i don't filter the route based on vertex-id.? My question is about the high-lighted portion below. Any answers highly appreciated? kris (4) Possibly modify the routing table. For those routing table entries modified, the associated area will be set to Area A, the path type will be set to intra-area, and the cost will be set to the newly discovered shortest path's calculated distance. Moy Standards Track [Page 164] RFC 2328 OSPF Version 2 April 1998 If the newly added vertex is an area border router or AS boundary router, a routing table entry is added whose destination type is "router". The Options field found in the associated router-LSA is copied into the routing table entry's Optional capabilities field. Call the newly added vertex Router X. If Router X is the endpoint of one of the calculating router's virtual links, and the virtual link uses Area A as Transit area: the virtual link is declared up, the IP address of the virtual interface is set to the IP address of the outgoing interface calculated above for Router X, and the virtual neighbor's IP address is set to Router X's interface address (contained in Router X's router-LSA) that points back to the root of the shortest- path tree; equivalently, this is the interface that points back to Router X's parent vertex on the shortest-path tree (similar to the calculation in Section 16.1.1). If the newly added vertex is a transit network, the routing table entry for the network is located. The entry's Destination ID is the IP network number, which can be obtained by masking the Vertex ID (Link State ID) with its associated subnet mask (found in the body of the associated network-LSA). If the routing table entry already exists (i.e., there is already an intra-area route to the destination installed in the routing table), multiple vertices have mapped to the same IP network. For example, this can occur when a new Designated Router is being established. In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. If there is no routing table entry for the network (the usual case), a routing table entry for the IP network should be added. The routing table entry's Link State Origin should be set to the newly added vertex' LSA. --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. --0-1550345506-1145904410=:5820 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi ,
 
 What is the significance of Vertex-id in Intra_SPF run. RFC-2328 says when the metrics are equal we should filter the route based on Vertex-id.
 
I am attaching contents from RFC 2328 16.1 paragraph. My question is whether we can have any topologies which can run in this situation? Is this only a transit condition ? or any topology can have this one as persistant condition? Whats the problem if i don't filter the route based on vertex-id.? My question is about the high-lighted portion below.
 
 
Any answers highly appreciated?
 
kris
 
 
(4) Possibly modify the routing table.  For those routing table
            entries modified, the associated area will be set to Area A,
            the path type will be set to intra-area, and the cost will
            be set to the newly discovered shortest path's calculated
            distance.




Moy                         Standards Track                   [Page 164]

RFC 2328                     OSPF Version 2                   April 1998


            If the newly added vertex is an area border router or AS
            boundary router, a routing table entry is added whose
            destination type is "router".  The Options field found in
            the associated router-LSA is copied into the routing table
            entry's Optional capabilities field. Call the newly added
            vertex Router X.  If Router X is the endpoint of one of the
            calculating router's virtual links, and the virtual link
            uses Area A as Transit area:  the virtual link is declared
            up, the IP address of the virtual interface is set to the IP
            address of the outgoing interface calculated above for
            Router X, and the virtual neighbor's IP address is set to
            Router X's interface address (contained in Router X's
            router-LSA) that points back to the root of the shortest-
            path tree; equivalently, this is the interface that points
            back to Router X's parent vertex on the shortest-path tree
            (similar to the calculation in Section 16.1.1).

            If the newly added vertex is a transit network, the routing
            table entry for the network is located.  The entry's
            Destination ID is the IP network number, which can be
            obtained by masking the Vertex ID (Link State ID) with its
            associated subnet mask (found in the body of the associated
            network-LSA).  If the routing table entry already exists
            (i.e., there is already an intra-area route to the
            destination installed in the routing table), multiple
            vertices have mapped to the same IP network.  For example,
            this can occur when a new Designated Router is being
            established.  In this case, the current routing table entry
            should be overwritten if and only if the newly found path is
            just as short and the current routing table entry's Link
            State Origin has a smaller Link State ID than the newly
            added vertex' LSA.

            If there is no routing table entry for the network (the
            usual case), a routing table entry for the IP network should
            be added.  The routing table entry's Link State Origin
            should be set to the newly added vertex' LSA.

Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. --0-1550345506-1145904410=:5820-- --===============1400004487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1400004487==-- From ospf-bounces@ietf.org Mon Apr 24 18:43:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9ld-0007qE-31; Mon, 24 Apr 2006 18:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9lb-0007q9-V0 for ospf@ietf.org; Mon, 24 Apr 2006 18:42:51 -0400 Received: from [203.199.83.33] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FY9lX-0008GJ-Uo for ospf@ietf.org; Mon, 24 Apr 2006 18:42:51 -0400 Received: (qmail 3033 invoked by uid 510); 24 Apr 2006 22:41:50 -0000 Date: 24 Apr 2006 22:41:50 -0000 Message-ID: <20060424224150.3032.qmail@webmail47.rediffmail.com> Received: from unknown (63.80.1.198) by rediffmail.com via HTTP; 24 apr 2006 22:41:50 -0000 MIME-Version: 1.0 From: "badvel vishnu reddy" To: ospf@ietf.org Subject: Re: [OSPF] question about generating default route NSSA X-Spam-Score: 1.5 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: badvel vishnu reddy List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0648754758==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============0648754758== Content-type: multipart/alternative; boundary="Next_1145918510---0-203.199.83.33-3030" This is a multipart mime message --Next_1145918510---0-203.199.83.33-3030 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi =0A Have a question regarding the router that generates the NSSA defaul= t. =0A=0AI have two ABR's generating default NSSA LSA. I know that the one = with the highest routerID should continue generating and the one with lowes= t routerID stop generating. I am not able to understand the advantage in ch= oosing the router that generates the TYPE7 default. =0AIf both of them cont= inue generating the default type7 LSA then the routers near to the first AB= R will choose the first ABR as next hop and the routers near to the second = ABR can choose the second ABR as the next hop.Instead if only one of them g= enerates the type7 default then the routers need to select this ABR only ev= en if there is one more ABR very near to it. Appreciate the responses.=0A= =0AThanks=0A=0ARegards,=0AVishnu=0A=0ARegards,=0AVishnu --Next_1145918510---0-203.199.83.33-3030 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi
=0A  Have a question regarding the router that generates = the NSSA default.
=0A
=0AI have two ABR's generating default NSSA LS= A. I know that the one with the highest routerID should continue generating= and the one with lowest routerID stop generating. I am not able to underst= and the advantage in choosing the router that generates the TYPE7 default. =
=0AIf both of them continue generating the default type7 LSA then the r= outers near to the first ABR will choose the first ABR as next hop and the = routers near to the second ABR can choose the second ABR as the next hop.In= stead if only one of them generates the type7 default then the routers need= to select this ABR only even if there is one more ABR very near to it. App= reciate the responses.
=0A
=0AThanks
=0A
=0ARegards,
=0AVish= nu
=0A
=0ARegards,
=0AVishnu=0A

=0A

=0A= =0A --Next_1145918510---0-203.199.83.33-3030-- --===============0648754758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0648754758==-- From ospf-bounces@ietf.org Mon Apr 24 19:11:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYADB-0006Zl-L9; Mon, 24 Apr 2006 19:11:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYADA-0006Zg-1k for ospf@ietf.org; Mon, 24 Apr 2006 19:11:20 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYAD8-0001B1-OS for ospf@ietf.org; Mon, 24 Apr 2006 19:11:20 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Apr 2006 16:11:18 -0700 X-IronPort-AV: i="4.04,153,1144047600"; d="scan'208"; a="1798229315:sNHT31096232" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3ONBGYi028459; Mon, 24 Apr 2006 16:11:17 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 19:11:16 -0400 Received: from [10.21.122.110] ([10.21.122.110]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 19:11:16 -0400 Message-ID: <444D5B12.7010706@cisco.com> Date: Mon, 24 Apr 2006 19:11:14 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: badvel vishnu reddy Subject: Re: [OSPF] question about generating default route NSSA References: <20060424224150.3032.qmail@webmail47.rediffmail.com> In-Reply-To: <20060424224150.3032.qmail@webmail47.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2006 23:11:16.0305 (UTC) FILETIME=[63584C10:01C667F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Vishnu, badvel vishnu reddy wrote: >Hi > Have a question regarding the router that generates the NSSA default. > >I have two ABR's generating default NSSA LSA. I know that the one with the highest routerID should continue generating and the one with lowest routerID stop generating. I am not able to understand the advantage in choosing the router that generates the TYPE7 default. > > I also see no advantage. The rule you quote is from RFC 2328, 12.4.4.1. It only applies if the AS external (type 5) or NSSA (type 7) LSAs have the same non-zero forwarding addresses. In the case of the type 7 default LSAs injected by the ABRs, the forwarding address should be zero. Thanks, Acee >If both of them continue generating the default type7 LSA then the routers near to the first ABR will choose the first ABR as next hop and the routers near to the second ABR can choose the second ABR as the next hop.Instead if only one of them generates the type7 default then the routers need to select this ABR only even if there is one more ABR very near to it. Appreciate the responses. > >Thanks > >Regards, >Vishnu > >Regards, >Vishnu > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Apr 26 01:10:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYcHg-0002uN-Od; Wed, 26 Apr 2006 01:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYcHe-0002uI-Gp for ospf@ietf.org; Wed, 26 Apr 2006 01:09:50 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYcHU-0002GP-Gv for ospf@ietf.org; Wed, 26 Apr 2006 01:09:50 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00H0JD25MN@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 26 Apr 2006 13:10:53 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IYB00A2VD24F2@szxga03-in.huawei.com> for ospf@ietf.org; Wed, 26 Apr 2006 13:10:53 +0800 (CST) Received: from dell60 ([10.18.7.113]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IYB00FT2DIB4O@szxml01-in.huawei.com> for ospf@ietf.org; Wed, 26 Apr 2006 13:20:37 +0800 (CST) Date: Wed, 26 Apr 2006 10:32:40 +0530 From: sujay Subject: RE: [OSPF] question about RFC 2636 In-reply-to: <20060424184650.6968.qmail@web38302.mail.mud.yahoo.com> To: ospf@ietf.org Message-id: <011601c668ee$a553de40$7107120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1703625368==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1703625368== Content-type: multipart/alternative; boundary="Boundary_(ID_UH5WVXdWfGswZR6ABMH6xg)" This is a multi-part message in MIME format. --Boundary_(ID_UH5WVXdWfGswZR6ABMH6xg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Punati, Vertex Id is an identifier for a Router, when specified by a Router LSA and a Network when specified by a Network LSA. It is the only way to identify nodes in the spf graph. =20 The text you have mentioned is very much a possible scenario as it says when the DR is coming up for the first=20 time. =20 It can easily happen in a Broadcast network (say ethernet)with varied metrics across the physical links=20 Regds, Sujay -----Original Message----- From: v punati [mailto:vpunkris@yahoo.com]=20 Sent: Tuesday, April 25, 2006 12:17 AM To: ospf@ietf.org Subject: [OSPF] question about RFC 2636 Hi , =20 What is the significance of Vertex-id in Intra_SPF run. RFC-2328 says when the metrics are equal we should filter the route based on Vertex-id. =20 I am attaching contents from RFC 2328 16.1 paragraph. My question is whether we can have any topologies which can run in this situation? Is this only a transit condition ? or any topology can have this one as persistant condition? Whats the problem if i don't filter the route based on vertex-id.? My question is about the high-lighted portion below. =20 =20 Any answers highly appreciated? =20 kris =20 =20 (4) Possibly modify the routing table. For those routing table entries modified, the associated area will be set to Area A, the path type will be set to intra-area, and the cost will be set to the newly discovered shortest path's calculated distance. Moy Standards Track [Page 164] RFC 2328 OSPF Version 2 April 1998 If the newly added vertex is an area border router or AS boundary router, a routing table entry is added whose destination type is "router". The Options field found in the associated router-LSA is copied into the routing table entry's Optional capabilities field. Call the newly added vertex Router X. If Router X is the endpoint of one of the calculating router's virtual links, and the virtual link uses Area A as Transit area: the virtual link is declared up, the IP address of the virtual interface is set to the IP address of the outgoing interface calculated above for Router X, and the virtual neighbor's IP address is set to Router X's interface address (contained in Router X's router-LSA) that points back to the root of the shortest- path tree; equivalently, this is the interface that points back to Router X's parent vertex on the shortest-path tree (similar to the calculation in Section 16.1.1). If the newly added vertex is a transit network, the routing table entry for the network is located. The entry's Destination ID is the IP network number, which can be obtained by masking the Vertex ID (Link State ID) with its associated subnet mask (found in the body of the associated network-LSA). If the routing table entry already exists (i.e., there is already an intra-area route to the destination installed in the routing table), multiple vertices have mapped to the same IP network. For example, this can occur when a new Designated Router is being established. In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. If there is no routing table entry for the network (the usual case), a routing table entry for the IP network should be added. The routing table entry's Link State Origin should be set to the newly added vertex' LSA. _____ =20 Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2=A2/min or less.=20 --Boundary_(ID_UH5WVXdWfGswZR6ABMH6xg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Message
Punati,
Vertex Id is an = identifier for=20 a Router, when specified by a Router LSA
and a Network when = specified by=20 a Network LSA.
It is the only way = to identify=20 nodes in the spf graph.
 
The text you have = mentioned is=20 very much a possible
scenario as it says = when the DR=20 is coming up for the first
time.
 
It can easily happen in a Broadcast network (say ethernet)with=20 varied
metrics across the  physical links
Regds,
Sujay
-----Original Message-----
From: v = punati=20 [mailto:vpunkris@yahoo.com]
Sent: Tuesday, April 25, 2006 = 12:17=20 AM
To: ospf@ietf.org
Subject: [OSPF] question = about RFC=20 2636

Hi ,
 
 What is the significance of Vertex-id in Intra_SPF run. = RFC-2328=20 says when the metrics are equal we should filter the route based on=20 Vertex-id.
 
I am attaching contents from RFC 2328 16.1 paragraph. My = question is=20 whether we can have any topologies which can run in this situation? Is = this=20 only a transit condition ? or any topology can have this one as = persistant=20 condition? Whats the problem if i don't filter the route based on = vertex-id.?=20 My question is about the high-lighted portion below.
 
 
Any answers highly appreciated?
 
kris
 
 
(4) Possibly modify the routing table.  For those routing=20 = table
          &nbs= p;=20 entries modified, the associated area will be set to Area=20 = A,
            = the=20 path type will be set to intra-area, and the cost=20 = will
           = ; be=20 set to the newly discovered shortest path's=20 = calculated
          = ; =20 = distance.




Moy       = ;            =      =20 Standards=20 = Track           &n= bsp;      =20 [Page 164]

RFC=20 = 2328           &nb= sp;        =20 OSPF Version=20 = 2            =       =20 April=20 = 1998


         &nb= sp; =20 If the newly added vertex is an area border router or=20 = AS
            = boundary router, a routing table entry is added=20 = whose
          &nbs= p;=20 destination type is "router".  The Options field found=20 = in
            = the=20 associated router-LSA is copied into the routing=20 = table
          &nbs= p;=20 entry's Optional capabilities field. Call the newly=20 = added
          &nbs= p;=20 vertex Router X.  If Router X is the endpoint of one of=20 = the
           = =20 calculating router's virtual links, and the virtual=20 = link
           = ;=20 uses Area A as Transit area:  the virtual link is=20 = declared
          &= nbsp;=20 up, the IP address of the virtual interface is set to the=20 = IP
            = address of the outgoing interface calculated above=20 = for
           = =20 Router X, and the virtual neighbor's IP address is set=20 = to
            = Router X's interface address (contained in Router=20 = X's
           = =20 router-LSA) that points back to the root of the=20 = shortest-
          =  =20 path tree; equivalently, this is the interface that=20 = points
          &nb= sp;=20 back to Router X's parent vertex on the shortest-path=20 = tree
           = ;=20 (similar to the calculation in Section=20 = 16.1.1).

         &nb= sp; =20 If the newly added vertex is a transit network, the=20 = routing
          &n= bsp;=20 table entry for the network is located.  The=20 = entry's
          &n= bsp;=20 Destination ID is the IP network number, which can=20 = be
            = obtained by masking the Vertex ID (Link State ID) with=20 = its
           = =20 associated subnet mask (found in the body of the=20 = associated
          = ; =20 network-LSA).  If the routing table entry already=20 = exists
          &nb= sp;=20 (i.e., there is already an intra-area route to=20 = the
           = =20 destination installed in the routing table),=20 = multiple
          &= nbsp;=20 vertices have mapped to the same IP network.  For=20 = example,
          &= nbsp;=20 this can occur when a new Designated Router is=20 = being
          &nbs= p;=20 established.  In this case, the current routing table=20 = entry
          &nbs= p;=20 should be overwritten if and only if the newly found path=20 = is
            = just=20 as short and the current routing table entry's=20 = Link
           = ;=20 State Origin has a smaller Link State ID than the=20 = newly
          &nbs= p;=20 added vertex'=20 = LSA.

          &= nbsp;=20 If there is no routing table entry for the network=20 = (the
           = ;=20 usual case), a routing table entry for the IP network=20 = should
          &nb= sp;=20 be added.  The routing table entry's Link State=20 = Origin
          &nb= sp;=20 should be set to the newly added vertex' LSA.

Yahoo! Messenger with Voice. Make=20 PC-to-Phone Calls to the US (and 30+ countries) for 2=A2/min or = less.=20
--Boundary_(ID_UH5WVXdWfGswZR6ABMH6xg)-- --===============1703625368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1703625368==-- From ospf-bounces@ietf.org Wed Apr 26 10:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkfH-0002Tp-60; Wed, 26 Apr 2006 10:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYkfG-0002Tf-Eh for ospf@ietf.org; Wed, 26 Apr 2006 10:06:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYkfE-0006Dw-SC for ospf@ietf.org; Wed, 26 Apr 2006 10:06:46 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2006 07:06:44 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,158,1144047600"; d="scan'208"; a="26722525:sNHT926905712" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3QE6evL012087; Wed, 26 Apr 2006 10:06:43 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 10:06:41 -0400 Received: from [10.82.209.167] ([10.82.209.167]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 10:06:41 -0400 Message-ID: <444F7E70.6030402@cisco.com> Date: Wed, 26 Apr 2006 10:06:40 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v punati Subject: Re: [OSPF] question about RFC 2636 References: <20060424184650.6968.qmail@web38302.mail.mud.yahoo.com> In-Reply-To: <20060424184650.6968.qmail@web38302.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Apr 2006 14:06:41.0164 (UTC) FILETIME=[A444F4C0:01C6693A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org v punati wrote: >Hi , > > What is the significance of Vertex-id in Intra_SPF run. RFC-2328 says when the metrics are equal we should filter the route based on Vertex-id. > > I am attaching contents from RFC 2328 16.1 paragraph. My question is whether we can have any topologies which can run in this situation? Is this only a transit condition ? or any topology can have this one as persistant condition? > Hi Kris, If the transit network is physically partitioned, this situation could be persistent. If it is a transient condition, the routing table should converge once you've received updates for all the routers connected to the transit network. A similar conflict could occur between a transit network and stub due to partitioning or a misconfiguration. >Whats the problem if i don't filter the route based on vertex-id.? > I guess the motivation is to deterministically route to one of the network partitions. Since the network is partitioned or this is a transient condition, I really don't see much benefit in handling this case separately. Hope this helps, Acee > My question is about the high-lighted portion below. > > > Any answers highly appreciated? > > kris > > > (4) Possibly modify the routing table. For those routing table > entries modified, the associated area will be set to Area A, > the path type will be set to intra-area, and the cost will > be set to the newly discovered shortest path's calculated > distance. > > > > >Moy Standards Track [Page 164] > >RFC 2328 OSPF Version 2 April 1998 > > > If the newly added vertex is an area border router or AS > boundary router, a routing table entry is added whose > destination type is "router". The Options field found in > the associated router-LSA is copied into the routing table > entry's Optional capabilities field. Call the newly added > vertex Router X. If Router X is the endpoint of one of the > calculating router's virtual links, and the virtual link > uses Area A as Transit area: the virtual link is declared > up, the IP address of the virtual interface is set to the IP > address of the outgoing interface calculated above for > Router X, and the virtual neighbor's IP address is set to > Router X's interface address (contained in Router X's > router-LSA) that points back to the root of the shortest- > path tree; equivalently, this is the interface that points > back to Router X's parent vertex on the shortest-path tree > (similar to the calculation in Section 16.1.1). > > If the newly added vertex is a transit network, the routing > table entry for the network is located. The entry's > Destination ID is the IP network number, which can be > obtained by masking the Vertex ID (Link State ID) with its > associated subnet mask (found in the body of the associated > network-LSA). If the routing table entry already exists > (i.e., there is already an intra-area route to the > destination installed in the routing table), multiple > vertices have mapped to the same IP network. For example, > this can occur when a new Designated Router is being > established. In this case, the current routing table entry > should be overwritten if and only if the newly found path is > just as short and the current routing table entry's Link > State Origin has a smaller Link State ID than the newly > added vertex' LSA. > > If there is no routing table entry for the network (the > usual case), a routing table entry for the IP network should > be added. The routing table entry's Link State Origin > should be set to the newly added vertex' LSA. > > > >--------------------------------- >Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Apr 26 21:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYuyZ-0007pe-EG; Wed, 26 Apr 2006 21:07:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYuyX-0007pY-NO for ospf@ietf.org; Wed, 26 Apr 2006 21:07:21 -0400 Received: from [203.199.83.32] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYuyU-0004K8-MV for ospf@ietf.org; Wed, 26 Apr 2006 21:07:21 -0400 Received: (qmail 22609 invoked by uid 510); 27 Apr 2006 01:06:21 -0000 Date: 27 Apr 2006 01:06:21 -0000 Message-ID: <20060427010621.22608.qmail@webmail32.rediffmail.com> Received: from unknown (63.80.1.198) by rediffmail.com via HTTP; 27 apr 2006 01:06:21 -0000 MIME-Version: 1.0 From: "badvel vishnu reddy" To: "ospf" X-Spam-Score: 1.6 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [OSPF] Re:Generating type5 LSA in ospfv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: badvel vishnu reddy List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1793540513==" Errors-To: ospf-bounces@ietf.org This is a multipart mime message --===============1793540513== Content-type: multipart/alternative; boundary="Next_1146099981---0-203.199.83.32-22606" This is a multipart mime message --Next_1146099981---0-203.199.83.32-22606 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =A0=0AHi All,=0AIn OSPFV3 since the link state ID's of an external LSA's c= an be anything if i use the address prefix with an algorithm that generates= the number, there is always a possibility that there exists the same netwo= rk but with different prefix length, so in this regard OSPV2 escapes by usi= ng rfc 2328 sec E. An algorithm for assigning Link State IDs.=0AIn the con= text of OSPFV3 what should be done since RFC 2740 doesn't specify anything.= =0ARegards,=0AVishnu --Next_1146099981---0-203.199.83.32-22606 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A 
=0AHi All,
=0AIn OSPFV3 since the link state ID's of an= external LSA's can be anything if i use the address prefix with an algorit= hm that generates the number, there is always a possibility that there exis= ts the same network but with different prefix length, so in this regard OSP= V2 escapes by using  rfc 2328 sec E. An algorithm for assigning Link S= tate IDs.
=0AIn the context of OSPFV3 what should be done since RFC 2740= doesn't specify anything.
=0ARegards,
=0AVishnu=0A

=0A

=0A= =0A --Next_1146099981---0-203.199.83.32-22606-- --===============1793540513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1793540513==-- From ospf-bounces@ietf.org Wed Apr 26 21:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYvL5-0007nD-K3; Wed, 26 Apr 2006 21:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYvL4-0007n8-1P for ospf@ietf.org; Wed, 26 Apr 2006 21:30:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYvL2-0005Q6-Pt for ospf@ietf.org; Wed, 26 Apr 2006 21:30:38 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2006 21:30:38 -0400 X-IronPort-AV: i="4.04,159,1144036800"; d="scan'208"; a="87323415:sNHT107355820" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3R1UavF000403; Wed, 26 Apr 2006 21:30:36 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 21:30:36 -0400 Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Apr 2006 21:30:35 -0400 Message-ID: <44501EBB.7070409@cisco.com> Date: Wed, 26 Apr 2006 21:30:35 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: badvel vishnu reddy Subject: Re: [OSPF] Re:Generating type5 LSA in ospfv3 References: <20060427010621.22608.qmail@webmail32.rediffmail.com> In-Reply-To: <20060427010621.22608.qmail@webmail32.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2006 01:30:35.0900 (UTC) FILETIME=[2EE0C3C0:01C6699A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ospf X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org badvel vishnu reddy wrote: > >Hi All, >In OSPFV3 since the link state ID's of an external LSA's can be anything if i use the address prefix with an algorithm that generates the number, there is always a possibility that there exists the same network but with different prefix length, so in this regard OSPV2 escapes by using rfc 2328 sec E. An algorithm for assigning Link State IDs. >In the context of OSPFV3 what should be done since RFC 2740 doesn't specify anything. > > Nothing - Refer to section 2.2 in RFC 2740. In OSPFv3, the Link State ID has no addressing semantics. For inter-area prefix LSAs, inter-area-router-LSAs, external LSAs, and NSSA LSAs, the Link State ID is simply a number which must be unique for LSAs of the same type originated within the same flooding scope by the same advertising router. Hope this helps, Acee >Regards, >Vishnu > > >------------------------------------------------------------------------ > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf