Subject: [Sidrops] Multiple origin validation states in draft-ietf-sidrops-validating-bgp-speaker

From: John Scudder <[email-masked]>
Date: Tue, 23 Jul 2019 20:10:53 +0000

My comment at the mic was based on the verbal description of the slide. What I see in the draft text is different:

5.4.  Error Handling at Peers

   A route sent by a validating BGP speaker SHOULD only contain none or
   one EBGP Prefix Origin Validation State Large Community.

   A peer receiving a route from a validating BGP speaker containing
   more than one EBGP Prefix Origin Validation State Large Community
   SHOULD only consider the largest value (as described in Table 1) in
   the validation result field and disregard the other values.  Values
   larger than two in the validation result field MUST be disregarded.

This is different from what was described verbally. The written version seems fine to me. So, I would like to withdraw my comment.

I do suggest changing both SHOULD to MUST unless you can think of a use case for doing differently; if you can I suggest adding a MAY clause to describe the exception case.

Thanks,

—John

---

From: Daniel Kopp <[email-masked]>
Date: Tue, 23 Jul 2019 21:15:32 +0000

Hi John, 

thanks for pointing this out and clarifying your comment.

I’m sorry for the confusion. I was verbally interpreting the section to extensive, I think :)
A talked to the other authors and it seems that 5.4 is meant to be an addition/similar to 5.2.

So even that the route server must strip any Prefix Origin Validation State it receives,
5.4 serves as an extra protection in case things go wrong.

Let me know if you think we should remove 5.4.

Thanks for your comment!
Daniel

> On 23. Jul 2019, at 22:10, John Scudder <jgs=[email-masked]> wrote:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 23 Jul 2019 17:38:01 -0400 (Eastern Sommerzeit)

> Let me know if you think we should remove 5.4.
  why? if you consider this a possible situation, you should discuss how 
to handle the error.

  personally, i tend to say ignore the validation outcome at all. it is 
an error. as Job wrote "We can't really trust it."

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: John Scudder <[email-masked]>
Date: Tue, 23 Jul 2019 22:33:00 +0000

On Jul 23, 2019, at 5:15 PM, Daniel Kopp <[email-masked]<mailto:[email-masked]>> wrote:

No, I think it’s proper to provide guidance for what to do in this situation and I appreciate your doing it. As to the ongoing discussion of whether the strategy you give in that section is the right one or if a different one should be used, I’m agnostic — it’s enough that there is a defined strategy, as far as I’m concerned.

—John