80 likes | 258 Views
RFC 4601 Errata. RFC 4601 Errata Overview. Lots of stuff reported – should we do anything about it? http://www.rfc-editor.org/errata_search.php?rfc=4601 110 records in total, states as follows: Verified: 1 Wrong reference, should maybe “held for update” Reported: 1
E N D
RFC 4601 Errata Overview • Lots of stuff reported – should we do anything about it? • http://www.rfc-editor.org/errata_search.php?rfc=4601 • 110 records in total, states as follows: • Verified: 1 • Wrong reference, should maybe “held for update” • Reported: 1 • Poor wording, should be “held for update” • Rejected: 17 • Held for document update: 91
Editorial stuff, more or less (53) • Trivial editorial things (47 records) • 1094-1098, 1101, 1108-1109, 1111-1112, 1115-1117, 1126-1127, 1129-1131, 1134, 1136-1141, 1144, 1147, 1149-1150, 1155, 1163-1165, 1172, 1178-1180, 1182, 1186-1190, 1197, 1199-1202 • Asking for 2219 keywords to be capitalized (19 records) • 1122-1123, 1142, 1145-1146, 1151-1152, 1154, 1156-1157, 1181, 1183-1185, 1192, 1194-1195, 1198, 1200 • Asking for ( ) since left associativity not specified. (6 records) E.g. • immediate_olist(*,G) = joins(*,G) (+) pim_include(*,G) (-) lost_assert(*,G) • 1104-1107, 1110, 1128
Security considerations (6) • Link-local security, forged messages, holdtime infinity • 1113-1114, 1119, 1133 (4) • Wants more discussion on security, DoS attacks, how PIM relies on routing • 1135, 1201
Non-important (11) • 1121 should probably be rejected • 1124 missing text, but fairly obvious • 1143, 1168, 1170 • Not sure I get it, reject or add quick clarification • 1161 should maybe be clarified • 1162, 1167 point out that traffic may be dropped for a while, not sure if should do anything • 1166 asks for clarification, don’t think it’s needed • 1169 asks for clarification, maybe needed but not important • 1193 asks for clarification. I think it’s obvious, but if this person missed it…
1159: (S,G,rpt)-state & (S,G)-joins • Figure 5, (S,G,rpt) state machine • (S,G,rpt)-join makes us go P/PP -> NI • Should (S,G)-joins do the same?
1160:(*,G)-j/(S,G,rpt)-p & (S,G,rpt)-j • Section 4.5.4 says: • Receive Prune(S,G,rpt) The compound Join/Prune message contains a Prune(S,G,rpt). The (S,G,rpt) downstream state machine on interface I transitions back to the Prune-Pending state… • Errata note: • Infinite toggle for every pair of routers where one wants (*,G) and the other wants (*,G) and (S,G,rpt). State moves from Prune -> PruneTmp -> NI -> Prune for the (S,G,rpt) state machine. This causes upstream thrash with Join(S,G,rpt) followed by Prune(S,G,rpt) in continual succession. Which causes Prune (S,G,rpt) state to be state limited to never actually enter Prune state (NI -> PP -> NI). • If the situation is two downstream routers on same interface, then if one sends (*,G)-join/(S,G,rpt)-prune, the other with just (*,G) will override the prune • We then periodically go NI -> PP -> NI • Is this what the errata note is trying to say? • Issues with this?
Action required? • It looks bad having this long list of erratas • We would certainly take care of most of them if we update RFC 4601 • Are the erratas sufficient reason? • Are there other reasons why we might want to update RFC 4601?