Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
RFC 3684
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2004-02-20
|
11 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2004-02-20
|
11 | (System) | RFC published |
|
2003-11-04
|
11 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2003-11-03
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2003-11-03
|
11 | Amy Vezza | IESG has approved the document |
|
2003-11-03
|
11 | (System) | Last call text was added |
|
2003-11-03
|
11 | (System) | Ballot approval text was added |
|
2003-10-31
|
11 | Amy Vezza | Removed from agenda for telechat - 2003-10-30 by Amy Vezza |
|
2003-10-30
|
11 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
|
2003-10-24
|
11 | Alex Zinin | State Changes to IESG Evaluation from IESG Evaluation::Revised ID Needed by Alex Zinin |
|
2003-10-24
|
11 | Alex Zinin | Placed on agenda for telechat - 2003-10-30 by Alex Zinin |
|
2003-10-15
|
11 | (System) | New version available: draft-ietf-manet-tbrpf-11.txt |
|
2003-10-10
|
11 | Alex Zinin | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Alex Zinin |
|
2003-10-10
|
11 | Alex Zinin | Asked the authors to address some more IESG comments: 1. Some statement on what's known about the correctness of the protocol, its proof, etc. … Asked the authors to address some more IESG comments: 1. Some statement on what's known about the correctness of the protocol, its proof, etc. Pointers would be good. No need to include the proof in the doc, just a brief statement. 2. Question: > The number of nodes that can be supported depends on several factors, > including the data rate, the rate of topology changes, and the > network density (average number of neighbors). Simulations have shown > that TBRPF can support 250 nodes in mobile networks using IEEE 802.11 > with a data rate of 2 Mbps. is 2Mbps the user data rate? do we know how much the protocol itself consumed? 3. Router ID > Each node is identified by a unique 32-bit router ID (RID), > which for IPv4 is equal to the IP address of one of its > interfaces. The term "node u" denotes the node whose RID is > equal to u. > so, in v4 is is mandatory that it is an ip address of an > interface, but in v6 it is arbitrary? why perpetuate the bgp > routerid confusion? > and, given that the definition of 'interface' precludes virtual > interfaces, commonly known today as 'loopbacks', in v4 one can not > use common ops practice, and in v6 things become muddy. 4. Link notation: > In the following overview of the operation of TND, we assume that > interface I belongs to node i, and interface J belongs to node j. > When a node i changes the status of a link (I,J), it includes the > neighbor interface address J in the appropriate list (NEIGHBOR > REQUEST/REPLY/LOST) in at most NBR_HOLD_COUNT (typically 3) > consecutive HELLOs sent on interface I. This ensures that node j will > either receive one of these HELLOs on interface J, or will miss > NBR_HOLD_COUNT HELLOs and thus declare the link (J,I) to be LOST. > yes, the notiation defined for bi-dir links seems to be unordered, > but would it not be clearer if that last (J,I) was (I,J)? |
|
2003-09-04
|
11 | Amy Vezza | Removed from agenda for telechat - 2003-09-04 by Amy Vezza |
|
2003-09-04
|
11 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2003-08-25
|
11 | Alex Zinin | Placed on agenda for telechat - 2003-09-04 by Alex Zinin |
|
2003-08-21
|
11 | Amy Vezza | Removed from agenda for telechat - 2003-07-10 by Amy Vezza |
|
2003-08-14
|
11 | Alex Zinin | Placed on agenda for telechat - 2003-07-10 by Alex Zinin |
|
2003-08-14
|
11 | Alex Zinin | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Alex Zinin |
|
2003-08-14
|
11 | Alex Zinin | -10 addresses the IESG comments (below). putting on the agenda for the next telechat. - the document appears to just grab the address from … -10 addresses the IESG comments (below). putting on the agenda for the next telechat. - the document appears to just grab the address from the unallocated space, rather than request it. - the document does not mention such address allocation in the IANA section. |
|
2003-07-29
|
10 | (System) | New version available: draft-ietf-manet-tbrpf-10.txt |
|
2003-07-10
|
11 | Amy Vezza | State Changes to IESG Evaluation :: AD Followup from IESG Evaluation by Vezza, Amy |
|
2003-07-03
|
11 | Alex Zinin | -09 ready to go. putting on the agenda. |
|
2003-07-03
|
11 | Alex Zinin | State Changes to IESG Evaluation from AD Evaluation :: Revised ID Needed by Zinin, Alex |
|
2003-06-26
|
09 | (System) | New version available: draft-ietf-manet-tbrpf-09.txt |
|
2003-06-06
|
11 | Alex Zinin | Comments from the rtg-dir provided to the authors on May 7, 2003. Waiting for the new rev. >I am conducting a routing directorate (rtg-dir) review … Comments from the rtg-dir provided to the authors on May 7, 2003. Waiting for the new rev. >I am conducting a routing directorate (rtg-dir) review of this draft, and >I have a few (relatively trivial) comments/questions. I would be grateful >for your responses. > > Mike Shand > > > > >1. Introduction > > The term "proactive routing protocol" has a specific meaning > within the MANET context. It might be useful for readers unfamiliar with > the concept to give a brief definition in the "terminology" section. > >4. Applicability Section > >Is there some evidence to support the claim "it can support networks with >up to a few hundred nodes".? >e.g. that is the design scope, or simulations and or implementations >support this. > >5.1 Overview of neighbor discovery > >There seems to be an inconsistency in the use of MUST/MAY in this section >(and possibly in other sections as well). > >In para 7 "must" appears uncapitalized. This seems reasonable, given that >this is just an overview. > >However, in the last para we have "MAY". > >6.1 TBRFP Packet header >F- flag extension. Should it say that when using F to insert single octet >of padding, the flag extension bits MUST be zero? > >C- Checksum included. >The phrase "a 16 bit checksum beginning in the first octet of the header >extension" is ambiguous, since it is not (yet) clear whether the >"beginning" refers to the data over which the checksum is calculated, or >the location of the computed checksum. Subsequent text reveals that it is >the latter, but this could be made clear by saying something like > >"a 16 bit checksum in the first two octets of the header extension". > >Also, this mechanism means that a single bit error (clearing the C bit) >can result in undetected corruption. Note that in this case the 16 bits of >checksum will be interpreted as something else. Is that a concern? > >6.2 TBRPF Packet Body > >This use of TLVs is somewhat strange. Normally the L field is always >present immediately after the T field and hence a new (and not recognized) >type can be introduced, such that it is simply parsed over and ignored. >This cannot be done with the proposed structure. IPv6 option TLVs DO have >the normal property. It is probably confusing to call the TBRPF messages TLVs > >The draft doesn't say what to do with non-recognized type values. Drop the >packet? > >6.2.1 Padding Options > >Senders MAY > > >Is the use of the F bit to insert a one octet pad redundant because of >the existence of the Pad1 option? Or are the two intended to serve >different purposes. (the former inserts padding prior to the length and >router ID header extensions). It seems odd to have TWO mechanisms to >achieve the same ends. > >7.8 Configurable parameters. > >MAX_JITTER Jitter is usually expressed as a percentage, not an absolute >value, and value of 25% is typical. Is there a particular reason for >specifying it this way? > >10.6 Support for nonMANET Hosts > >Should there be a section about how a TBRPF domain interfaces with the >internet at large? Are there any special considerations? Or is everything >which needs to be covered dealt with in section 10.5? > > > >That's all I have. I haven't reviewed the protocol specification for >correctness. I assume the authors and WG have already done that:-) |
|
2003-06-06
|
11 | Alex Zinin | State Changes to AD Evaluation :: Revised ID Needed from Publication Requested by Zinin, Alex |
|
2003-04-25
|
11 | Alex Zinin | Draft Added by Zinin, Alex |
|
2003-04-22
|
08 | (System) | New version available: draft-ietf-manet-tbrpf-08.txt |
|
2003-03-07
|
07 | (System) | New version available: draft-ietf-manet-tbrpf-07.txt |
|
2002-11-06
|
06 | (System) | New version available: draft-ietf-manet-tbrpf-06.txt |
|
2002-03-07
|
05 | (System) | New version available: draft-ietf-manet-tbrpf-05.txt |
|
2002-01-14
|
04 | (System) | New version available: draft-ietf-manet-tbrpf-04.txt |
|
2001-11-29
|
03 | (System) | New version available: draft-ietf-manet-tbrpf-03.txt |
|
2001-09-06
|
02 | (System) | New version available: draft-ietf-manet-tbrpf-02.txt |
|
2001-03-06
|
01 | (System) | New version available: draft-ietf-manet-tbrpf-01.txt |
|
2000-08-31
|
00 | (System) | New version available: draft-ietf-manet-tbrpf-00.txt |