Re: [Sidrops] [WGLC] draft-sidrops-bgpsec-validation-signaling-03 - ends 17/September/2020

[Keyur Patel <[e-mail]>]

Thanks for the comments/clarifications Nick. __

On 9/21/20, 1:42 PM, "Nick Hilliard" <[e-mail]> wrote:

    Keyur Patel wrote on 10/09/2020 18:27:
    > The wg chairs extended the call for a week in hopes that we would have a 
    > consensus. Seems like more discussion is needed and so we plan extend 
    > the call for 1 more week. TheWGLCwill now end on September 17, 2020

    this comment is coming a bit late in the day, but I think it would be an 
    idea to clarify the behaviour of the receiving bgp side a little better.

    >    A receiving BGPsec enabled router SHOULD use the received BGPsec path
    >    validation state in situations where a locally computed BGPsec
    >    validation result is not currently available.  In the absence of the
    >    extended community, the receiving BGPsec enabled router MUST NOT make
    >    any assumption about the validation sate of the UPDATE.

    The second sentence is a no-op, so it would probably be better to remove it.

    The draft intends that the bgp receiver treats routes with this extcomm 
    as if they were locally validated by bgpsec.  The simplified state 
    outcome is:

    1. the receiving bgp implementation has bgpsec enabled, and has computed 
    a local validation result for the incoming prefix

    2. the receiving bgp implementation supports bgpsec, but has not 
    computed a local validation result for the incoming prefix

    3. the receiving bgp implementation does not support bgpsec.

    At the moment, the text deals with case #2.  Probably what you want to 
    do here is state that local validation takes preference over the 
    community value.

    Here's some suggested text as a replacement for the paragraph above, 
    which deals with #1 and #2:

    >    A receiving BGPsec enabled router SHOULD use the received BGPsec path
    >    validation state in situations where a locally computed BGPsec
    >    validation result is not currently available.  If a locally computed BGPsec
    >    validation result is available, then the received BGPsec path validation
    >    state MUST be ignored.
    I'm not sure what you intend with state #3. The choices here are: SHOULD 
    implement alternative policy handling mechanism, SHOULD NOT implement 
    alternative policy handling mechanism, or no advice.

    Some of this behaviour could be synthesised using normal policy hooks in 
    the bgp stack's configuration grammar, but that would need coding and 
    could be messy if there were ever future plans to support bgpsec because 
    then there would be two frameworks, probably incompatible with each 
    other.  It would certainly be easier for implementers to state that the 
    draft is not intended for bgp stacks which don't already implement 
    bgpsec.  Do the authors have any thoughts on this one?

    Nick