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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
