draft-ietf-rpsec-bgpsecrec-06.txt

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
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec

 

> 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.


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



_______________________________________________
RPSEC mailing list
RPSECietf.org
https://
www1.ietf.org/mailman/listinfo/rpsec