RE: [[e-mail]: Re: BGP4 stuff: Local Preference Computation]

["NITTMANN Michael (MSMail)" <[e-mail]>]

Transitive is wrong for MED, agree.
It should however be mandatory on ebgp connections. That implementations 
currently in the field will not be compliant with this is the way things 
work: standards develop, protocol implementations must follow.

With the 4 bits (only those that repeat protocol definitions): the protocol 
definition should be in the end engines. There is no need to duplicate that 
info on the network and really waste 4 bits for it. Looking at one message, 
4 bits seems few. Looking at all BGP exchanges in an AS, 4 bits less per 
route exchanged is a sizable quantity. 
Carrying an extended size flag is only useful if the same parameter exists 
in 'normal' and 'extended' size. 

What the use does as described:
only the transitive bit allows for a shade of compatibility, when an older 
implementation does not know a parameter, but it is flagged transitive: the 
implementation could treat this quantity as a blackbox and just pass it on 
together with the route. I doubt that this is really done anywhere, I 
suppose that most implementations will fail when they encounter an unknown 
attribute, and not pass it untreated on in case it were a transitive one.

The others just repeat what the programmers should have coded anyways, and 
what should be, e.g., in include files, to deliver faster and better error 
processing when parsing PEs. Since we change things, I would suggest not to 
carry superfluous information in an application layer protocol.

Carrying such info only causes more parsing overhead for unused exit 
conditions, and does also provide more possibilities for errors.

Protocol and engine relationships:

engine:                                                  protocol
  contains rules                      transmits context free data
  knows semantics                 between engines

I would agree for the necessity of a protocol to transport not only data and 
state information, but also rule and semantics information, when the engines 
are of some artificial intelligence type and can, e.g., detect a new 
attribute and insert it into the existing grammar database, including the 
rules (the 4 bits that describe the attribute as, e.g., transitive, 
sensitivity in different environments, etc.). But that's not the case here 
at all.

Summary: I would cut out the attribute description bits, leave the 
'extended' attribute in if it refers to attributes that exist in both 
formats, an extended and a 'normal' one, and I would make the exchange of 
MED mandatory on EBGP connections, with the provision that '-1' means 'none 
set', and not 'best of all', which in turn should be 0 (zero).

Mike



----------
From:  John G. Scudder[SMTP:[e-mail]]
Sent:  Monday, September 09, 1996 4:23 PM
To:  NITTMANN Michael (MSMail)
Cc:  [e-mail]
Subject:  RE: [[e-mail]: Re: BGP4 stuff: Local Preference Computation]

[cc list trimmed]

At 12:43 PM -0600 9/9/96, NITTMANN Michael (MSMail) wrote:
>MED should be transitive and mandatory on all ebgp connections; doesn't 
look
>so difficult to me.

I disagree that MED should be transitive/mandatory.  That is, I agree with
Curtis.  The question is not whether it is difficult, but whether it's
useful/needed.  (Well, there's also a question of whether it's
interoperable with current implementations.)

>these 4 bits, what's the purpose at all? Are the property bits for
>attributes in fact part of the transmitted protocol message (transitive,
>etc....)?

Yes, every BGP Path Attribute has an 8-bit FLAGS field.  (Perhaps a
read-through of the RFC (or I-D) would be in order before continuing this
dialogue.)

>Any real use transmitting protocol definition elements in run time PEs?

The transitive bit tells a BGP implementation if it should propagate an
unrecognized attribute to external peers.  It's clearly useful at runtime.

The optional bit, if not set, tells a BGP implementation that there's a big
problem if it receives a non-optional attribute which it doesn't recognize.
(The need for this one is open to question, but it doesn't hurt.)

The partial bit tells a BGP implementation if the entire path supports the
given attribute.  I don't know if anyone uses this for anything, but one
can certainly see how it may be useful.

The extended length bit's utility should be obvious to the most casual 
reader.

Regards,

--John

--
John Scudder                        email:  [e-mail]
Internet Engineering Group, LLC     phone:  [phone]
122 S. Main, Suite 280              fax:    [phone]
Ann Arbor, MI  41804                www:    http://www.ieng.com