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

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Tue, 23 Jul 2019 20:16:23 +0000

So we are talking about a single update containing two instances of the validation result community?   

Now, I really wonder how this can happen?   

Isn't this a sign that the RS is either (a) broken and inserting two results itself, or (b) the RS is ignoring the requirement to strip the community upon receipt?

dougm
--- 
Doug Montgomery @ NIST / ITL / ANTD  

On 7/23/19, 4:11 PM, "Sidrops on behalf of John Scudder" <[email-masked] on behalf of jgs=[email-masked]> wrote:

    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
    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7C05d79330bd044b01e38d08d70fa9f40e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636995094938987004&amp;sdata=f2GbGNJKpHR4a6RblTNYfCdTWYVyXiEYVZOdVXadqP0%3D&amp;reserved=0

---

From: Job Snijders <[email-masked]>
Date: Tue, 23 Jul 2019 20:18:15 +0000

> Isn't this a sign that the RS is either (a) broken and inserting two results itself, or (b) the RS is ignoring the requirement to strip the community upon receipt?

Or it didn't come from the route server, or the route server just
passed it on. We can't know from the BGP session itself whether the
route server does validation, and we can't know where the route server
got its routing information from. We can't really trust it.

Kind regards,

Job