Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt

From: [email-masked]
Date: Fri, 21 Jul 2006 13:21:43 -0400 (EDT)

Iljitsch van Beijnum said:

>> By "new BGP messages", do we mean messages in the BGP definition
>> of message types?
>
>That's what I meant, yes.
>
>> So new attributes would not be considered new messages?
>
>No, new attributes would be considered new attributes.  :-)

If you are talking about new messages, you don't have to worry about 
negotiating the capability (i.e., in order to avoid overloading an 
unaware recipient) - if a recipient sees a message type it doesn't 
understand, the BGP spec says it drops the connection.

>As I've tried to say before: we should only use this mechanism for
>information which is still useful after traversing one or more non-
>upgraded hops AND only if we can be reasonably sure that currently
>deployed routers won't run into trouble because of the extra memory
>required to store this information.

A valid concern.  But it is difficult to phrase into a requirement,
since some mechanisms may be "still useful" or may not "run into
trouble".  It could be expressed in the requirement document as
a warning to mechanism developers - "must consider the impact", etc.

>> even if the recipient was going to ignore them
>> (bandwidth, etc.).
>
>???
>
>I don't think ignoring messages is valid behavior in BGP.

BGP ignores (parts of) messages all the time.  Optional non-transitive
attributes are *required* to be ignored, if the recipient does not
recognize them.  That's all I meant.

>Only in new message types or modified current message types. This is
>certainly desired since sending this information to an unsuspecting
>router may lead to all kinds of upredictable results. Encoding the
>information in new path attributes is a different matter, existing
>implementations should handle those, but see above.

As I noted above, new message types lead to quite predictable behavior
- the connection gets dropped by an unsuspecting router (oiy).  Changes 
to existing messages, outside of adding new attributes like you said, 
would (almost certainly?) violate the existing requirement for incremental 
deployment, so I don't think that's something that requires stating a
new requirement, either.

>If I speak to you in a language you don't understand the relevance of
>the message is immaterial, you're not going to understand it.

Yes, but if I repeat it verbatim to someone who understands the
language, they will get the message.  (This analogy works better if it's
a note you write and I pass on.  :-) )

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: "Tony Li" <[email-masked]>
Date: Fri, 21 Jul 2006 11:47:52 -0700

> understand, the BGP spec says it drops the connection.

Any solution that results in BGP peerings being dropped would be
immediately undeployed.  Thus, I think it's reasonable that we require
that new BGP messages be first capability negotiated.  There is no need
for such a requirement for new path attributes.

Tony