Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance
RFC 4222
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
09 | (System) | Notify list changed from <acee@redback.com>, <rohit@utstar.com> to <rohit@utstar.com> |
2012-08-22 |
09 | (System) | post-migration administrative database adjustment to the No Objection position for Bert Wijnen |
2012-08-22 |
09 | (System) | post-migration administrative database adjustment to the No Objection position for David Kessens |
2012-08-22 |
09 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2005-10-20 |
09 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2005-10-20 |
09 | Amy Vezza | [Note]: 'RFC 4222 BCP 112' added by Amy Vezza |
2005-10-11 |
09 | (System) | RFC published |
2005-03-21 |
09 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-03-17 |
09 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2005-03-17 |
09 | Brian Carpenter | Created "Approve" ballot |
2005-03-16 |
09 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-03-16 |
09 | Amy Vezza | IESG has approved the document |
2005-03-16 |
09 | Amy Vezza | Closed "Approve" ballot |
2005-03-16 |
09 | Bill Fenner | State Changes to Approved-announcement to be sent from IESG Evaluation by Bill Fenner |
2005-03-16 |
09 | Bill Fenner | Removed from agenda for telechat - 2005-03-17 by Bill Fenner |
2005-03-16 |
09 | David Kessens | [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens |
2005-03-09 |
09 | Bill Fenner | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Bill Fenner |
2005-03-09 |
09 | Bill Fenner | State Change Notice email list have been change to <acee@redback.com>, <rohit@utstar.com> from <john.moy@sycamorenet.com>, <acee@redback.com>, <rohit@utstar.com> |
2005-03-09 |
09 | Bill Fenner | Placed on agenda for telechat - 2005-03-17 by Bill Fenner |
2005-03-09 |
09 | Bill Fenner | [Note]: 'Checking if -09 fixes concerns' added by Bill Fenner |
2005-01-03 |
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-01-03 |
09 | (System) | New version available: draft-ietf-ospf-scalability-09.txt |
2004-07-05 |
09 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen |
2004-06-24 |
09 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-06-24 |
09 | Alex Zinin | [Ballot comment] Section 2, point 5--calculation of the number of adjacencies includes "link bandwidth". What seems to be related is the total BW available for … [Ballot comment] Section 2, point 5--calculation of the number of adjacencies includes "link bandwidth". What seems to be related is the total BW available for the control plane, not one of an individual link, since the number of links may changes depending on the router configuration and link status. |
2004-06-23 |
09 | David Kessens | [Ballot discuss] The document states: --- In this document as we refer to OSPF we usually mean OSPFv2 [Ref1]. The scalability and stability improvement techniques … [Ballot discuss] The document states: --- In this document as we refer to OSPF we usually mean OSPFv2 [Ref1]. The scalability and stability improvement techniques described here may also apply to OSPFv3 [Ref2] but that will require further study and operational experience. --- This document needs to be more precise with it's definitions. 'we usually mean OSPFv2' is very vague. How can a reader know when the authors mean OSPFv2, OSPFv3 or OSPF in general ? Also, the title of the document should probably be 'OSPFv2 scalability' considering that the document says that further study is needed whether it also applies to OSPFv3. |
2004-06-23 |
09 | David Kessens | [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens |
2004-06-23 |
09 | Harald Alvestrand | [Ballot comment] Reviewed by Spencer Dawkins, Gen-ART |
2004-06-22 |
09 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-06-21 |
09 | Steven Bellovin | [Ballot discuss] My original DISCUSS said this: "This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That … [Ballot discuss] My original DISCUSS said this: "This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled. In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders." I'm unhappy with one of the proposed changes; for now, my DISCUSS stands. Saying that the priority treatment scheme should be applied at the receiver can work, though it will cause implementation complexity for the security handler: security processing (including sequence number checking) will have to be done at receive time, before the priority queueing. But the document goes on to suggest two sequence number spaces, one for high priority packets and one for low priority packets. The authors note that this change isn't backwards-compatible, and must be signaled explicitly or implicitly. But there is no explicit signaling defined, so that's not an option. Nor is there adequate analysis of other possible effects of having separate sequence number spaces. To give one example, would having that help or hinder the calculations in Recommendation 4 of the number of unacknowledged LSAs? My suggestion is to delete the part about dual sequence number spaces. If it looks like a good idea after further analysis, it can be the subject of a separate RFC, one that would include signaling and/or negotiation. The suggestion about receiver priorities is a good one and will suffice for this purpose, but there should be some discussion about the effects of congestion on the ability to actually benefit from this. Also, is receiver priority implemented, per RFC 1264? |
2004-06-21 |
09 | Steven Bellovin | [Ballot discuss] My original DISCUSS said this: "This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That … [Ballot discuss] My original DISCUSS said this: "This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled. In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders." I'm unhappy with one of the proposed changes; for now, my DISCUSS stands. Saying that the priority treatment scheme should be applied at the receiver can work, though it will cause implementation complexity for the security handler: security processing (including sequence number checking) will have to be done at receive time, before the priority queueing. But the document goes on to suggest two sequence number spaces, one for high priority packets and one for low priority packets. The authors note that this change isn't backwards-compatible, and must be signaled explicitly or implicitly. But there is no explicit signaling defined, so that's not an option. Nor is there adequate analysis of other possible effects of having separate sequence number spaces. To give one example, would having that help or hinder the calculations in Recommendation 4 of the number of unacknowledged LSAs? My suggestion is to delete the part about dual sequence number spaces. If it looks like a good idea after further analysis, it can be the subject of a separate RFC, one that would include signaling and/or negotiation. The suggestion about receiver priorities is a good one and will suffice for this purpose, but there should be some discussion about the effects of congestion on the ability to actually benefit from this. |
2004-06-21 |
09 | Steven Bellovin | [Ballot discuss] My original DISCUSS said this: This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That … [Ballot discuss] My original DISCUSS said this: This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled. In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders. I'm unhappy with one of the proposed changes; for now, my DISCUSS stands. Saying that the priority treatment scheme should be applied at the receiver can work, though it will cause implementation complexity for the security handler: security processing (including sequence number checking) will have to be done at receive time, before the priority queueing. But the document goes on to suggest two sequence number spaces, one for high priority packets and one for low priority packets. The authors note that this change isn't backwards-compatible, and must be signaled explicitly or implicitly. But there is no explicit signaling defined, so that's not an option. Nor is there adequate analysis of other possible effects of having separate sequence number spaces. To give one example, would having that help or hinder the calculations in Recommendation 4 of the number of unacknowledged LSAs? My suggestion is to delete the part about dual sequence number spaces. If it looks like a good idea after further analysis, it can be the subject of a separate RFC, one that would include signaling and/or negotiation. The suggestion about receiver priorities is a good one and will suffice for this purpose, but there should be some discussion about the effects of congestion on the ability to actually benefit from this. |
2004-06-14 |
09 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2004-06-11 |
09 | Bill Fenner | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Bill Fenner |
2004-06-11 |
09 | Bill Fenner | Replies from the document editor to the IESG evaluation: Response to IESG Reviewer's Comments: Comments From Ned Freed: Comment 1: Not sure if the separate … Replies from the document editor to the IESG evaluation: Response to IESG Reviewer's Comments: Comments From Ned Freed: Comment 1: Not sure if the separate sequence number business mentioned in the security considerations section is really a "security issue" with a "recommended" solution. To me it sounds more like a processing requirement for correct operation. But this is not my area of expertise so I'll leave it up to the security folks. Response 1: Please see the response to Steve Bellovin's comment below. Comment 2 : Nits: A fair number of grammar errors appear throughout. (date) in copyright boilerplate needs to be filled in. I don't think the copyright on the doc qualifies as an IP consideration, so it seems strange to see it as a list item in the IP considerations section. Response 2: We looked carefully at the document and corrected grammar errors wherever possible. (date) in copyright boilerplate is filled in as (2004). We made it clear that the "Copyright Notice" is not part of "IP Considerations". Comments from Steve Bellovin: Comment 1: This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled. In other words, it's not only not backwards compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders. Response 1: We understand your concern and address it as follows. We now recommend that in OSPFv2 and with Cryptographic Authentication (AuType = 2), no prioritized processing be done at the transmitter since that may cause packets to be received out of sequence and break the Cryptographic authentication. We do, however, recommend prioritized treatment at the receiver after receiving a valid OSPF packet since it does not cause the out of sequence problem. Also we mention that prioritized processing at transmitter can only be done if both sides of the interface use separate sequence number spaces for "High" and "Low" priority packets and can signal that fact to each other explicitly or implicitly (the fact that this mechanism is not backwards-compatible is also mentioned). The specific text used in this respect in Page 3 is given below (also similar clarifications given on Page 6 and Page 13): "The prioritized processing while transmitting may cause OSPF packets from a neighbor to be received out of sequence. In OSPFv2if Cryptographic Authentication (AuType = 2) is used (as specified in [Ref1]) then successive received valid OSPF packets from a neighbor need to have a non-decreasing "Cryptographic sequence number". To comply with this requirement we recommend that in case Cryptographic Authentication (AuType = 2) is used [Ref1], prioritized processing be done only at the receiver after receiving a valid OSPF packet but no prioritized processing be done at the transmitter. Another possibility is to use two separate sequence number spaces, one for "high" priority packets and another for "low" priority packets. In this case prioritized treatment at the transmitter would also work since OSPF packets within the same priority class would not get out of order. This mechanism is, however, not backwards compatible and so can be used only if both sides of the interface use this mechanism and can signal that fact to each other explicitly or implicitly." Comments From Ted Hardie: Comment 1: Appendix A lists Router-ID changes as one of the potential causes of an LSA storm, and notes that this condition may cause a large number of LSA purges as well as LSA re-originations. This raises for me the question of whether there is or needs to be ordering of LSA messages by type (e.g. process purges, then origination messages). The core idea of this (different class for control messages) is not affected by this, since all of the control messages still fall into the same class, but it might affect the implementation of some of the related features (FCFS for the formation of adjacencies, for example, might by within that particular set of LSA control messages, rather than being FCFS for all control messages). If this is handled by normal OSPF processing or not important for other reasons, mentioning why in the text might be a useful guide to the less experienced reader. Response 1: We added a Suggestion (3) in Appendix C (Page 13) to address your point. We also got input on this item from Alex Zinin, Rohit Dube, and Acee Lindem. "Processing large number of LSA Purges: Occasionally some events in the network, such as Router ID changes, may result in a large number of LSA re-originations and LSA purges. In such a scenario one may consider processing LSAs in different order, e.g., processing LSA purges ahead of LSA originations. We, however, do not recommend out-of-order LSA processing for several reasons. Firstly, detecting the LSA type ahead of queueing may be computationally expensive. Out-of-order processing may also cause subtle bugs. We do not want to recommend a major change in the LSA processing paradigm for a relatively rare event such as Router ID change. However, a Router with a changing ID may flush the old LSAs gradually without causing a storm." Comments From Russ Housley: Comment 1: Building on Steve's point: The OSPF sequence number is a 32-bit unsigned integer. If the OSPF Hellos and LSA Acknowledgments draw from one segment of this space, and other messages draw from another segment, then implementations of the current OSPF specification will reject one of the segments altogether. Response 1: We understand your point and made appropriate changes. Please see the response to Steve Bellovin's comment above. Comments From Bert Wijnen: Comment 1) This document only refers to OSPF as OSPFv2. How about OSPFv3? Either way, this requires modifications/clarifications. Response 1: To address your point we have added a reference to OSPFv3 (RFC 2740) and added the following text at the beginning of Introduction: "In this document as we refer to OSPF we usually mean OSPFv2 [Ref1]. The scalability and stability improvement techniques described here may also apply to OSPFv3 [Ref2] but that will require further study and operational experience." Comment 2) this document talks about "point-to-point links", but this maybe should be generalized, considering work on treating physical LAN links as point-to-point from the protocol's perspective (ref: draft-ietf-isis-igp-p2p-over-lan-03.txt)? Response 2: At the end of Section 2, Recommendations (Page 6), we have added the following text to address your point: "In some of the Recommendations above we refer to point-to-point links. Those references should also include cases where a broadcast network is to be treated as a point-to-point connection from the standpoint of IP routing [Ref5]". Comment 3) (I'm not 100% familiar with OSPF internals, but) assume that a malicious host sends an OSPF packet, over e.g. 5 hops, directly to a router, addresses to the routers unicast address. Would this be possible? Would it then be classified to be a received packet per rule (2) in section 2? Maybe this wouldn't work, but if it would, this would be one way to perform DoS by keeping up the adjacencies even if a router has failed (to send the packets to black hole or whatever). Response 3: If the adjacency is really down then no packets will come over it and so it will be declared down by OSPF within a period of RouterDeadInterval. After that OSPF will not accept any packet over the interface besides Hello packets. However, we would also like to point out that the DoS attack can occur even with normal OSPF (without our recommendations) if there is no authentication mechanism in place. Our recommendations do not make the situation any better or worse. Further Comments from Bert Wijnen Comment 1: The references lists over a dozen references which are many probably interesting, but not referred to in the body of the document. Remove or refer. Response 1: All references are referred to in the document. However, the Normative References and a subset of the Informative references are referred to in Sections 1-4. The rest are referred to in the Appendix Sections. |
2004-06-11 |
09 | Bill Fenner | Placed on agenda for telechat - 2004-06-24 by Bill Fenner |
2004-06-11 |
09 | Bill Fenner | [Note]: 'Additional response to each evaluation comment in comment log' added by Bill Fenner |
2004-06-07 |
08 | (System) | New version available: draft-ietf-ospf-scalability-08.txt |
2004-05-26 |
07 | (System) | New version available: draft-ietf-ospf-scalability-07.txt |
2003-12-18 |
09 | Amy Vezza | Removed from agenda for telechat - 2003-12-18 by Amy Vezza |
2003-12-18 |
09 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2003-12-18 |
09 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for by Amy Vezza |
2003-12-18 |
09 | Amy Vezza | [Ballot Position Update] New position, Yes, has been recorded for by Amy Vezza |
2003-12-18 |
09 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for by Thomas Narten |
2003-12-18 |
09 | Bert Wijnen | [Ballot comment] Nit from OPS directorate review (Pekka): The references lists over a dozen references which are many probably interesting, but not referred to in … [Ballot comment] Nit from OPS directorate review (Pekka): The references lists over a dozen references which are many probably interesting, but not referred to in the body of the document. Remove or refer. |
2003-12-18 |
09 | Bert Wijnen | [Ballot discuss] From OPS DIrectorate review (Pekka): Big issues: 1) This document only refers to OSPF as OSPFv2. How about OSPFv3? Either way, this requires … [Ballot discuss] From OPS DIrectorate review (Pekka): Big issues: 1) This document only refers to OSPF as OSPFv2. How about OSPFv3? Either way, this requires modifications/clarifications. 2) this document talks about "point-to-point links", but this maybe should be generalized, considering work on treating physical LAN links as point-to-point from the protocol's perspective (ref: draft-ietf-isis-igp-p2p-over-lan-03.txt)? 3) (I'm not 100% familiar with OSPF internals, but) assume that a malicious host sends an OSPF packet, over e.g. 5 hops, directly to a router, addresses to the routers unicast address. Would this be possible? Would it then be classified to be a received packet per rule (2) in section 2? Maybe this wouldn't work, but if it would, this would be one way to perform DoS by keeping up the adjacencies even if a router has failed (to send the packets to black hole or whatever). |
2003-12-18 |
09 | Bert Wijnen | [Ballot discuss] From OPS DIrectorate review (Pekka): Big issues: 1) This document only refers to OSPF as OSPFv2. How about OSPFv3? Either way, this requires … [Ballot discuss] From OPS DIrectorate review (Pekka): Big issues: 1) This document only refers to OSPF as OSPFv2. How about OSPFv3? Either way, this requires modifications/clarifications. 2) this document talks about "point-to-point links", but this maybe should be generalized, considering work on treating physical LAN links as point-to-point from the protocol's perspective (ref: draft-ietf-isis-igp-p2p-over-lan-03.txt)? 3) (I'm not 100% familiar with OSPF internals, but) assume that a malicious host sends an OSPF packet, over e.g. 5 hops, directly to a router, addresses to the routers unicast address. Would this be possible? Would it then be classified to be a received packet per rule (2) in section 2? Maybe this wouldn't work, but if it would, this would be one way to perform DoS by keeping up the adjacencies even if a router has failed (to send the packets to black hole or whatever). |
2003-12-18 |
09 | Bert Wijnen | [Ballot Position Update] New position, Discuss, has been recorded for by Bert Wijnen |
2003-12-18 |
09 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for by Jon Peterson |
2003-12-18 |
09 | Alex Zinin | [Ballot Position Update] New position, Yes, has been recorded for by Alex Zinin |
2003-12-17 |
09 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for by Margaret Wasserman |
2003-12-17 |
09 | Russ Housley | [Ballot discuss] Building on Steve's point: The OSPF sequence number is a 32-bit unsigned integer. If the OSPF Hellos and LSA Acknowledgments draw from one … [Ballot discuss] Building on Steve's point: The OSPF sequence number is a 32-bit unsigned integer. If the OSPF Hellos and LSA Acknowledgments draw from one segment of this space, and other messages draw from another segment, then implementations of the current OSPF specification will reject one of the segments altogether. |
2003-12-17 |
09 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for by Russ Housley |
2003-12-16 |
09 | Ted Hardie | [Ballot comment] Appendix A lists Router-ID changes as one of the potential causes of an LSA storm, and notes that this condition may cause a … [Ballot comment] Appendix A lists Router-ID changes as one of the potential causes of an LSA storm, and notes that this condition may cause a large number of LSA purges as well as LSA re-originations. This raises for me the question of whether there is or needs to be ordering of LSA messages by type (e.g. process purges, then origination messages). The core idea of this (different class for control messages) is not affected by this, since all of the control messages still fall into the same class, but it might affect the implementation of some of the related features (FCFS for the formation of adjacencies, for example, might by within that particular set of LSA control messages, rather than being FCFS for all control messages). If this is handled by normal OSPF processing or not important for other reasons, mentioning why in the text might be a useful guide to the less experienced reader. |
2003-12-16 |
09 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for by Ted Hardie |
2003-12-16 |
09 | Steven Bellovin | [Ballot discuss] This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That RFC has no provision for the different sequence … [Ballot discuss] This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328. That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled. In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders. |
2003-12-16 |
09 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for by Steve Bellovin |
2003-12-13 |
09 | Ned Freed | [Ballot comment] Not sure if the separate sequence number business mentioned in the security considerations section is really a "security issue" with a "recommended" solution. … [Ballot comment] Not sure if the separate sequence number business mentioned in the security considerations section is really a "security issue" with a "recommended" solution. To me it sounds more like a processing reqirement for correct operation. But this is not my area of expertise so I'll leave it up to the security folks. Nits: A fair number of grammar errors appear throughout. (date) in copyright boilerplate needs to be filled in. I don't think the copyright on the doc qualifies as an IP consideration, so it seems strange to see it as a list item in the IP considerations section. |
2003-12-13 |
09 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for by Ned Freed |
2003-12-11 |
09 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner |
2003-12-11 |
09 | Bill Fenner | Ballot has been issued by Bill Fenner |
2003-12-11 |
09 | Bill Fenner | Created "Approve" ballot |
2003-12-09 |
09 | Alex Zinin | Placed on agenda for telechat - 2003-12-18 by Alex Zinin |
2003-12-09 |
09 | Alex Zinin | State Changes to IESG Evaluation from Waiting for Writeup by Alex Zinin |
2003-12-09 |
09 | Alex Zinin | putting on telechat for Bill |
2003-10-22 |
09 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2003-10-08 |
09 | Amy Vezza | Last call sent |
2003-10-08 |
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2003-10-07 |
09 | Bill Fenner | Last Call was requested by Bill Fenner |
2003-10-07 |
09 | Bill Fenner | State Changes to Last Call Requested from AD Evaluation by Bill Fenner |
2003-10-07 |
09 | (System) | Ballot writeup text was added |
2003-10-07 |
09 | (System) | Last call text was added |
2003-10-07 |
09 | (System) | Ballot approval text was added |
2003-10-07 |
09 | Bill Fenner | State Changes to AD Evaluation from Last Call Requested by Bill Fenner |
2003-10-07 |
09 | Bill Fenner | Why has this been allowed to languish in Last Call Requested for a month? |
2003-09-05 |
09 | Bill Fenner | State Changes to Last Call Requested from AD Evaluation by Bill Fenner |
2003-09-05 |
09 | Bill Fenner | From: Rohit Dube <rohit@utstar.com> Subject: Re: Working Group Last Call for draft-ietf-ospf-scalability-06.txt Date: Fri, 05 Sep 2003 15:13:54 -0400 To: Mailing … From: Rohit Dube <rohit@utstar.com> Subject: Re: Working Group Last Call for draft-ietf-ospf-scalability-06.txt Date: Fri, 05 Sep 2003 15:13:54 -0400 To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM> Cc: fenner@research.att.com, zinin@psg.com This working group call has ended without further comment. The drafts now goes back to the ADs. FYI, --rohit. |
2003-08-19 |
06 | (System) | New version available: draft-ietf-ospf-scalability-06.txt |
2003-06-17 |
09 | Bill Fenner | Intended Status has been changed to BCP from None |
2003-06-17 |
09 | Bill Fenner | State Changes to AD Evaluation from Publication Requested by Fenner, Bill |
2003-06-13 |
09 | Bill Fenner | Subject: Re: Working Group Last Call for draft-ietf-ospf-scalability-05.txt Date: Fri, 13 Jun 2003 11:03:58 -0400 From: Rohit Dube <rohit@xebeo.com> To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM> Cc: zinin@psg.com, … Subject: Re: Working Group Last Call for draft-ietf-ospf-scalability-05.txt Date: Fri, 13 Jun 2003 11:03:58 -0400 From: Rohit Dube <rohit@xebeo.com> To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM> Cc: zinin@psg.com, fenner@research.att.com This last call has ended and I am forwarding the draft to the ADs for review. --rohit. |
2003-06-13 |
09 | Bill Fenner | Draft Added by Fenner, Bill |
2003-05-29 |
05 | (System) | New version available: draft-ietf-ospf-scalability-05.txt |
2003-05-19 |
04 | (System) | New version available: draft-ietf-ospf-scalability-04.txt |
2003-04-01 |
03 | (System) | New version available: draft-ietf-ospf-scalability-03.txt |
2002-11-07 |
02 | (System) | New version available: draft-ietf-ospf-scalability-02.txt |
2002-04-25 |
01 | (System) | New version available: draft-ietf-ospf-scalability-01.txt |
2001-03-01 |
00 | (System) | New version available: draft-ietf-ospf-scalability-00.txt |