A few comments on the current draft.
Thanks Stephen,
-danny
---
Regarding this section:
BMP operates over TCP. All options are controlled by configuration
on the monitored router. No message is ever sent from the monitoring
station to the monitored router. The monitored router MAY take steps
to prevent the monitoring station from sending data (e.g. by half-
closing the TCP session or setting its window size to zero) or it MAY
silently discard any data erroneously sent by the monitoring station.
"... If the router is unable to connect to the monitoring station, it
periodically
retries the connection. .."
I'm not sure what this all means? When I first read it I had assumed that
you were referring to "No BMP message is ever sent from the monitoring
station .." but upon reading further it seems to suggest that you are
changing basic TCP behaviors here as well; the current recommendation
concerns me, as it creates non-deterministic failure conditions. Am I
missing something?
---
In S 3.5 how would an operator use the SR and Stat Data to determine, for
example, a particular prefix that was resulting in a large number of duplicate
advertisements? I'm inclined to think we should go ahead and specify that
"more complex TLV-type" stat data now, such that implementations that wish
to convey which prefixes are of interest can do so. Thoughts on this?
Also, it would allow us to discriminate in cases where, e.g., a cluster_list
loop
is actually a legitimate withdraw?
---
I wonder if S 3.5 or S 3.6 should have some additional text to accommodate
the new bgp error handling procedures being defined in IDR - e.g., flag these
updates as "special", and you could even address issues by others here with
TLV capabilities in S 3.5 that would allow inclusion of additional data, if need
be?
---
In S 9 I think if confidentiality is not the requirement but integrity is then
perhaps TCP-AO should be recommended?
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
