Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)

["Montgomery, Douglas (Fed)" <[e-mail]>]

While I support Jakob's idea of taking a reserved byte from RFC8097 for signaling path validation state, I am unclear what the proposed use of the value 3 is.   I will note, that explaining this proposed use in the context of the error handling rules of RFC8205 (https://tools.ietf.org/html/rfc8205#section-5.2) would be useful.

Having said that - getting agreement on how/where to encode the signal first - then hashing out any other code points other than the obvious ones would seem like the way to proceed.

dougm
--
Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST
 

On 9/25/19, 11:11 AM, "Roque Gagliano (rogaglia)" <[e-mail]> wrote:

    Hi,
    
    I do not believe your proposal of a new state is adequate:
       |   3   | Lookup result = "BGPSec attribute not present or in error"
    
    Looks to me that you want to add more context on the reasons for invalidating an update but that should not be in the "validation state":
    	- You could be in "unverified" state because the attribute was not present. 
    	- Independently if there was an "error" (whatever it means), the state will still be "invalid" as validation was tried and failed.
    
    Regards,
    Roque
    
    
    On 25.09.19, 17:01, "Sidrops on behalf of Borchert, Oliver (Fed)" <[e-mail] on behalf of oliver.borchert=[e-mail]> wrote:
    
        Jakob, 
        
        I agree, adding the BGPsec information into the RFC 8097 communities "reserved" field 
        seems definitely be a good solution and I can easily modify the proposed draft to do that.  
        
        Oliver
        
        -----Original Message-----
        From: Sidrops <[e-mail]> On Behalf Of Jakob Heitz (jheitz)
        Sent: Tuesday, September 24, 2019 3:32 PM
        To: Montgomery, Douglas (Fed) <dougm=[e-mail]>; Randy Bush <[e-mail]>; Keyur Patel <[e-mail]>
        Cc: [e-mail]
        Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
        
        I would be in favor of carving off another byte from the reserved field.
        Redefining the validation state to add the new information instead would confuse older receivers that do not understand the new code points.
        
        In addition, I would add another point to the BGPSec validation state: BGPSec attribute not present or in error.
        
           +-------+------------------------------+
           | Value | Meaning                      |
           +-------+------------------------------+
           |   0   | Lookup result = "Unverified" |
           |   1   | Lookup result = "Valid"      |
           |   2   | Lookup result = "Not valid"  |
           |   3   | Lookup result = "BGPSec attribute not present or in error"
           +-------+------------------------------+
        
        If it were to use a reserved byte of the RFC8097 community, 0 for unverified would work, I think.
        
        Regards,
        Jakob.
        
        -----Original Message-----
        From: Sidrops <[e-mail]> On Behalf Of Montgomery, Douglas (Fed)
        Sent: Monday, September 16, 2019 4:02 PM
        To: Randy Bush <[e-mail]>; Keyur Patel <[e-mail]>
        Cc: [e-mail]
        Subject: Re: [Sidrops] WG Adoption call for draft-borchert-sidrops-bgpsec-validation-signaling-01 (9/16-9/30)
        
        Randy,
        
        Are you suggesting keeping the 0x43 0x00 code point, but redefining its validation state byte with additional values and meanings for path validation?
        
        Or carving off another byte from reserved?
        
        Either of those sounds fine and save bits.   
        
        Clearly there would need to be a new spec that that adds the words to do that.
        
        dougm
        --
        Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST
         
        
        On 9/16/19, 5:13 PM, "Sidrops on behalf of Randy Bush" <[e-mail] on behalf of [e-mail]> wrote:
        
            "This document defines a new BGP non-transitive extended community to
            carry the BGPsec path validation state inside an autonomous system."
            
            given the one in RFC 8097, we need a new one because?
            
            randy
            
            _______________________________________________
         
        
        _______________________________________________
        Sidrops mailing list
        [e-mail]
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0
        _______________________________________________
        Sidrops mailing list
        [e-mail]
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0
        _______________________________________________
        Sidrops mailing list
        [e-mail]
        https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cdougm%40nist.gov%7Cb719ffb86d1c4bbae1d408d741caa222%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637050210864138120&amp;sdata=TL%2FHxcVgC2OY5c7PtSAcH%2FffM3Upy98O0qCoFyhuIL8%3D&amp;reserved=0