Subject: Re: [Idr] draft-scholl-idr-advisory-00

From: "David Freedman" <[email-masked]>
Date: Thu, 26 Mar 2009 01:55:24 -0000

>Maybe my grasp of english is not sufficient here, or I just don't get the 
>term, but what do you mean by "non-terminal notification"?

Sorry, it's quite late here, but to clarify, RFC4271 

sec 3 states:

"NOTIFICATION messages are sent in response to
   errors or special conditions.  If a connection encounters an error
   condition, a NOTIFICATION message is sent and the connection is
   closed.
"

sec 4.5 states:

"4.5.  NOTIFICATION Message Format

   A NOTIFICATION message is sent when an error condition is detected.
   The BGP connection is closed immediately after it is sent.
"

So basically, when a NOTIFICATION message is sent, the session must be closed, 
this is what I mean by "terminal".

I don't think it is right in all circumstances to terminate the session if the "condition"
is recoverable / nonfatal.

I think the ADVISORY message and its predecessor the INFORM both satisfy this, 
a way of informing you a "condition of interest" occured but that it was not 
an error, nor fatal to me (nor to you) and we should continue the session.

It should be optional to receive, negotiated by capability , the capability
should indicate that you can either send, receive or do both. If you have not negotiated
the capability, or negotiated the capability indicating that you will only send (and not receive)
then nobody should be sending to you, to do so would be an error on their part and you should reject 
such messages.

Since the messages are "in-band" with the session, they would be protected by the same
mechanisms (MD5/GTSM) that the session is protected with. 

The ability for the message to carry plain text (and not a plethora of attribute types/values) 
(but limited in size) allows us to be as flexible and as creative with the use as possible, 
the inter-noc communication is just one small application for this (potentially) enabling feature.

I understand the reluctance for add something which appears "non routing" to the protocol, but we already have these messages since they are related to the transport (and hence the routing path), the NOTIFICATION already exists (and has to), it was just a shame that we had to make it terminal in all cases.

Dave.

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net

---

From: Dong Jie <[email-masked]>
Date: Thu, 26 Mar 2009 14:14:38 +0800

Hi,

I agree that sending non-terminal information is necessary, but I still have
a question: does the ADVISORY message affect routing?

If the answer is Yes, then the message should be sent in-band and be parsed
by the peering router immediately, so the peering router can make some
reaction accordingly.

Under this circumstance, the message should not be in free-form, since it
needs to be understood by a router.

If the answer is No, the message is just some information about "condition
of interest", and is for operators (not for routers) to read it sometime
later, I think it's not quite necessary to send it in-band, and we can use
free-form text message here.

IMO, Maybe we could divide the messages into two types: "affect routing" or
"not affect routing", and treat them in different ways.

Best regards,

Dong Jie

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of David
Freedman
Sent: Thursday, March 26, 2009 9:55 AM
To: [email-masked]
Subject: Re: [Idr] draft-scholl-idr-advisory-00

So basically, when a NOTIFICATION message is sent, the session must be
closed,
this is what I mean by "terminal".

I don't think it is right in all circumstances to terminate the session if
the "condition"
is recoverable / nonfatal.

I think the ADVISORY message and its predecessor the INFORM both satisfy
this,
a way of informing you a "condition of interest" occured but that it was not
an error, nor fatal to me (nor to you) and we should continue the session.

It should be optional to receive, negotiated by capability , the capability
should indicate that you can either send, receive or do both. If you have
not negotiated
the capability, or negotiated the capability indicating that you will only
send (and not receive)
then nobody should be sending to you, to do so would be an error on their
part and you should reject
such messages.

Since the messages are "in-band" with the session, they would be protected
by the same
mechanisms (MD5/GTSM) that the session is protected with.

The ability for the message to carry plain text (and not a plethora of
attribute types/values)
(but limited in size) allows us to be as flexible and as creative with the
use as possible,
the inter-noc communication is just one small application for this
(potentially) enabling feature.

I understand the reluctance for add something which appears "non routing" to
the protocol, but we already have these messages since they are related to
the transport (and hence the routing path), the NOTIFICATION already exists
(and has to), it was just a shame that we had to make it terminal in all
cases.

Dave.

---

From: "Elmar K. Bins" <[email-masked]>
Date: Thu, 26 Mar 2009 11:28:54 +0100

Re David,

> Sorry, it's quite late here, but to clarify, RFC4271 

Ah, alright, got it.

Thanks for the clarification.

Elmar.

PS: If non-terminal notifications are so important to operators,
    why were they not included in named RFC, meaning, why has the
    session termination not being made optional for certain cases?
    Was there discussion? (I missed it)