Subject: Revised I-Ds

From: Dave Katz <[email-masked]>
Date: Mon, 17 May 2004 14:32:24 -0700

I just launched the updated versions of the I-Ds to the secretariat, so 
they should be appearing in the next day or two.

A version with security added should follow in the not-too-distant 
future.

--Dave (speaking for Dave2)

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 May 2004 09:49:03 +0300 (EEST)

> A version with security added should follow in the not-too-distant 

I mainly only checked the diffs between versions..

A few generic comments:
-----------------------

 - I'd suggest changing 'Changes from the previous draft' to 'Changes'
and having subsections like 'Changes from <draft-name-version>' and
keeping the change history of the old drafts.  This way the entire 
change history is kept intact, and there's smaller amount of wdiff 
churn ;-)

 - the last sections of the draft are in a relatively weird order
('Contributors', 'Acknowledgements', 'Authors Addresses', 'Changes',
'References', 'Security Considerations',...).  This is very atypical,
and should be changed. I'd shift up SecCons just After the
Acknowledgements, and References just after (new) SecCons.

A few comments on bfd-02:
-------------------------

 - 'category: Informational' at the header no longer applies
 - just one reference, and that to RFC2026? Oh my... :-)
 - a new text in section 2 states:

    BFD may^
   also be implemented in the control engine, though doing so may^
   preclude the detection of some kinds of failures.

==> I fail to understand this.  Running BFD on the control engine, 
with packets flowing through the forwarding path IMHO tests a 
super-set of functionality, not a subset.  I fail to see what kind of 
failures you couldn't note by a control plane implementation of BFD?

Actually now that I'm thinking about it, I'm not 100% what you mean by 
'control engine' in the first place..

A few comments on bfd-v4v6-1hop-01:
-----------------------------------

 - no static route or single-hop eBGP support yet? Anything I could 
   do to help..? (BGP should be straightforward; static routes a bit 
   trickier for address selection..)

 - this should probably be spelled out a bit:

  Each BFD session between a pair of systems MUST traverse a separate
   path in both directions.

==> that is, these don't need to use a separate _physical_ path, but 
what you want to say, I think, is that each BFD session must be 
independent of each other, so that if you ran e.g., OSPFv2 and IS-IS 
for v4 on the same link (weird but could be the case..), each would 
require a separate session?

 - still I think it would make sense to combine BFD for v4 and v6
sections; I already sent text for this.  The difference is just about
one sentence -- IMHO it's not worth keeping duplicate otherwise 
identical text apart :)

 - the new text:

   If a BFD session never comes up (possibly because the remote system^
   does not support BFD), this MUST NOT preclude the establishment of an
   OSPF neighbor or an IS-IS adjacency.

==> this requires a bit beefing up I think.  What's the definition of
'never comes up'?  I guess at the moment it's 
implementation-dependent, but it might not hurt to add some 
specification, pointers or suggestions here.

 - As for security considerations, you should add an Informational
reference to GTSM spec (for further background information), as that
spec includes quite a verbose discussion of the applicability and
usefulness of TTL=255 checks.

 - I'm quite concerned about the graceful restart part when BFD shares
fate with the control plane (which is probably the common scenario).  
That's all fine if you make the assumption that the routers have
redundant control planes and are able to smoothly switch over (without
losing a packet, or with very low delay) to the new control plane if
the previous one failed.  But if that isn't the case, BFD doesn't make
OSPF/IS-IS reliability any better, because instead of failing a link
and converging to a new path you end up waiting 5 minutes for the
router to come up and losing all the packets in the meanwhile. This
could be mitigated by placing a much more aggressive graceful-restart
timer to BFD (like 3-5 seconds).

I guess this is more of a concern on the whole graceful restart
concept (which seems to require very specific hardware and software
interactions to work properly) than for BFD..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings