BGP AS Path not supporting AS Path Stuffing

[marenamat]

In openconfig-rib-bgp-attributes.yang, grouping bgp-as-path-attr-state declares member as leaf-list which has unique elements by RFC. This way, AS Stuffed Path (like 65533 65533 65533 65500) generates YANG-invalid data. Dunno how to fix this, maybe even by updating the RFC to allow non-unique elements in leaf-list?

[dplore]

Thanks for bringing this up. It's not clear to me why we have a nested list of as-path numbers. I expect we would have just one flat, ordered list with an index as the key and one aspath per index. But for some reason the OC model has a nested model where there is a list of leaf-lists.

@aashaikh do you have any history on why we have a nested as-path model?

[marenamat]

Hello, the as-path structure is mapped 1:1 to RFC 4271, that's fine and it probably shouldn't get flattened. The problem is just the usage/definition of leaf-list.

Also note that by having an index-value structure, you're effectively making the AS path ridiculously unreadable for anybody (and also unreasonably large).

I would suggest to actually update the YANG RFC to add data types of "implicitly indexed ordered list of the same type" or something like that, and then use such a type. This kind of data structure is well representable in XML, JSON and CBOR and it's a pity that every list has to have explicit indexes just for nothing.

[dplore]

This is not really the forum to suggest changes to the yang language. If there is some format you suggest that would be more readable and legal in yang 1.0, we could entertain that.

[marenamat]

I think that you are posing a false dilemma. Adhering to bad tools is not a good thing just because everybody uses them. And regarding the fact that this issue was laying dormant for 9 months, there's definitly no rush and we can just wait for an improved YANG version. I'm ok with drafting that YANG update myself, btw, not calling for you to do it.

…

On 19 March 2024 17:26:16 CET, Darren Loher ***@***.***> wrote: This is not really the forum to suggest changes to the yang language. If there is some format you suggest that would be more readable and legal in yang 1.0, we could entertain that. -- Reply to this email directly or view it on GitHub: #932 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[dplore]

I am interested to see your proposal! Please do share what you are thinking in yang or even as a hypothetical tree structure to get the conversation started before writing/refactoring yang. (for example, the current portion of the tree we are discussing:)

  +--rw network-instances
     +--rw network-instance* [name]
        +--rw protocols
        |  +--rw protocol* [identifier name]
        |     +--rw bgp
        |     |  +--rw global
        |     |  +--ro rib
        |     |     +--ro attr-sets
        |     |     |  +--ro attr-set* [index]
        |     |     |     +--ro as-path
        |     |     |     |  +--ro as-segment* [index]
        |     |     |     |     +--ro index    -> ../state/index
        |     |     |     |     +--ro state
        |     |     |     |        +--ro index?    uint32
        |     |     |     |        +--ro type?     oc-bgpt:as-path-segment-type
        |     |     |     |        +--ro member*   oc-inet:as-number
        |     |     |     +--ro as4-path
        |     |     |     |  +--ro as4-segment* [index]
        |     |     |     |     +--ro index    -> ../state/index
        |     |     |     |     +--ro state
        |     |     |     |        +--ro index?    uint32
        |     |     |     |        +--ro type?     oc-bgpt:as-path-segment-type
        |     |     |     |        +--ro member*   oc-inet:as-number

[LimeHat]

@marenamat re: updating the RFC, this has been solved in yang 1.1 [for non-configuration data], rfc7950.