Chris,
I am talking about inter-domain policy not intra-domain. "ACHTUNG" may
not help as folks around seem very reluctant to share their internal
policies outside.
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.
Jakob,
I think this question is more about what step in the route selection
process (rfc 4271, 9.1.2.2) at which to consider the verification state.
I would answer: nowhere.
Really ? Assume there is no policy set by the operator. You have
received on your ASBR a net with two paths from two different upstreams.
One SIGNED containing sequence of embedded paths with pCounts hacks and
the other path with just old plane AS_PATH.
First you need to expand internally the signed path to mimic the old
AS_PATH format for comparison (both length and content for multipath).
So you can't just clearly do nothing with the signed path - I hope we
all agree on that.
Now let's talk policy. An operator would like to express his policy to
mean: "PREFER SIGNED PATHS ONLY IF NOT LONGER THEN NOT SIGNED PATHS"
How do you express such policy with local_pref or with cost_community
today ?
---
While I think it is very easy to say BGPSEC just works as enhancement to
today's policy I think I have illustrated above that it is not right
analogy in all case.
---
Also on the topic of other email reg replace-as functionality I
described in http://goo.gl/7aT5c what is router supposed to do when it
receives signed as_path and replace-as is in the in/out policy ?
Thx,
R.
On Thu, Mar 22, 2012 at 7:28 PM, Robert Raszuk<[email protected]> wrote:
By chaos I meant complete autonomous selection of what paths are preferred
to be chosen as best on an AS by AS basis. In the case of mixed SIGNED and
how is the above any different that what happens today? (inside a
single ASN, each router decides what it thinks is 'best', hopefully
with a coordinated policy across all devices, but ... that is not
guaranteed!)
UNSIGNED paths being consider in this _local_ decision as you stated it
seems to me just like it is the case with bad uncorrelated policies more
harm can be accomplished then good.
sure... should someone say: "ACHTUNG!! OPENZ PEEPERZ!! USE THE SAME
POLICY ON ALL DEVICES!!" ?
I think, I thought, I hope that the above message is (perhaps less
comically) stated to all network engineers when they graduate and get
their striped hats... (so thus NOT a required statement in an RFC-like
document)
-chris
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
