Subject: Re: [Idr] New Draft Notification:draft-dong-idr-fsm-subcode-00

From: Anantharamu Suryanarayana <[email-masked]>
Date: Wed, 3 Mar 2010 18:33:22 -0800

[
   Please ignore this email if this is a duplicate. I an facing some smtp
   server related issues when sending out of the network emails.
   So I am using Exchange-Outlook instead to send this reply once more.
]

Thanks for your review Jeff. My replies for some of your comments
are in line.

--
On Wed, Mar 03, 2010 at 07:03:58AM -0800, Jeffrey Haas wrote:
> Jie,
>
> Here are some comments on your draft.
>
> On Wed, Mar 03, 2010 at 11:49:33AM +0800, Jie Dong wrote:
> > There is a new internet draft: draft-dong-idr-fsm-subcode-00:
> > http://tools.ietf.org/html/draft-dong-idr-fsm-subcode-00
>
> This document deals with two scenarios:
> 1. Reporting additional information in the NOTIFICATION message.
> 2. Providing information to the local and remote system about the
> nature of transport session issues.
>
> In the case of the NOTIFICATION extensions, the changes are relatively
> minimal and should not impact the interoperability of existing BGP
> implementations.  There are potential conformance issues which I will
> address separately.  The addition of the notification subcodes
> provides good additional information as to why the FSM error occurred.
> However, it doesn't supply enough information to determine what
> message caused the error in question.  Additional clarification could
> be given in this situation by setting the NOTIFICATION Data field to
> be the value of the BGP Message type that caused the error.

TCP based errors may not be associated with a particular BGP message,
as TCP is stream based. For others, yes, we could pass on some part of
the unexpected message received.

> Subcode 4, error cause by TCP connection, is interesting.  In this
> case it is not a notification we're receiving from the peer but one
> that we are effectively pretending to have received.  One place this
> could be visible would be in the BGP MIBv2, e.g.
> bgp4V2PeerLastErrorSubCodeReceived or in the older MIB, bgpPeerLastError.
>
> While these subcodes are potentially interesting, they also introduce
> headaches for people who have to deal with conformance testing for
> their implementation.  Despite the fact that the semantics of the
> additional information available in either the code/subcode and data
> for a given notification may be clear, errors are often flagged by
> conformance tools when there are deviations from the core BGP
> specification.  While this shouldn't be a primary motivation to avoid
> changes to the spec, especially for a message type meant to tear down
> the peering session, I would suggest that there should be a reasonably
> high bar to introducing these sorts of changes.

I believe, idea here is to not only use new codes for trouble-shooting,
but also for potential BGP outbound performance improvements, by isolating
peers with TCP errors away from the rest of the normal and healthy peers
in a peer group.

> I am also confused about the motivation for this draft.  With the
> exception of the TCP error functionality, all of these subcodes should
> be seen only in cases where a BGP implementation is broken.  Seeing
> one of these subcodes in an operational network would seem to me to be
> an indication that the router causing it should be pulled from
> production immediately.  In other words, these subcodes seem mostly
> useful for development of an implementation, not deployment.

I agree that TCP based error is certainly the most important one among the
defined FSM error sub codes. That is the reason, we defined a way to carry
it and inform the peer in subsequent open message.

However, making it more explicit to cover all other FSM related errors would
not hurt. (Agreed, conformance tools need awareness as well to avoid false
positives)

> With regard to the session information capability, I'm not sure a
> capability is the best way to carry this information.  It's certainly
> the easiest to implement.  However, I have issues with the proposed content:

Currently in BGP, there does not seem to be an easier alternative to add
features/add new information without breaking backward compatibility which
is very critical obviously.

> For last flap cause, this will in every case but the transport error
> one be the notification message that the receiving peer had sent to
> the transmitting peer.  In the absence of additional data about the
> message type that caused the problem, knowing that a FSM error that
> occurred isn't useful enough to help troubleshoot the broken BGP implementation.

Intention is to consider a session 'flap'ed only when the BGP session state
moves out of established state. Thus essentially limits this last flap cause
To two of the 4 FSM error codes (3 - Receive Unexpected Message in Established
State and 4 - Error Caused by TCP connection problem)

> With regard to the BGP Speaker Description information type, while
> US-ASCII is certainly easy to implement, the IETF OPS group has been
> urging operational content to be displayed in MIBs in an
> international-friendly format with the encoding of UTF-8.

I see. We will certainly looking into UTF-8 format.

Another factor that I thought about is in traditional BGP packet debuggers like
tcpdump, wireshark, etc. They all can interpret ASCII already. So can, most of
the current BGP Implementations.

If BGP open messages were to carry a little more information in user friendly
text form, then it seems quite handy during BGP packet dump analysis as well,
especially when dealing with dumps/logs of multiple bgp sessions.

Thanks
--
Regards,
Ananth