Re: [sidr] Signed vs unsgned and bgp best path decision

[Robert Raszuk <[e-mail]>]

>> When compared to what is today I don't think folks are mandated by any RFC
>> to make a choice between two attributes which carry the same metric to
>> decide which one should win on a per AS basis.
>
> they are not, and in the future the 'mandate' is I believe a 'SHOULD',
> not a 'MUST' so not really a 'mandate', but a 'suggestion', eh?
>
> It seems that the intent of the effort here is really just to provide
> an informational blob to the operators which they can use as they see
> fit... much like other optional transitive attributes today.

Ok that sounds very reasonable indeed.

However number of folks have stated that bgpsec protocol proposal calls 
for replacing AS-PATH and AS4_PATH attributes with BGPSEC_Path_Sig 
attribute. In particular this text from 
/draft-ietf-sidr-bgpsec-protocol-02 sort of suggests that:

    The other option is that the BGPSEC speaker
    discards anything in the AS_PATH attribute and reconstructs the
    AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I
    believe that there are no interoperability problems if the choice
    between these two options is left up to the BGPSEC speaker.

Also it says in the same section 5:

    One option the
    BGPSEC speaker checks the AS_PATH attribute against the information
    in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
    two do not match.

That means that if AS_PATH for example contains AS_SET that someone 
doing BGP multipath (across non identical paths) has correctly inserted 
into AS_PATH or as mentioned before did replace-as the update will be 
dropped as BGPSEC just can not handle those ....


Meta question:

Can optional attribute result in such drastic actions (nothing to do 
with operator's choice of local behavior) against mandatory attribute(s) ?

Best,
R.