Re: [GROW] Working Group Call for draft-pels-grow-yang-bgp-communities (start 06/Dec/2023 end 06/Jan/2024)

[Dale W. Carder]

Thus spake Job Snijders (job=40fastly@dmarc.ietf.org) on Wed, Dec 06, 2023 
at 04:42:05PM +0100:
> Dear GROW,
> 
> The author of draft-pels-grow-yang-bgp-communities asked whether the
> GROW working group could consider adoption of their internet-draft.
> 
> This message is a request to the group for feedback on whether this
> internet-draft should be adopted.
> 
> Title: YANG Module for BGP Communities
> Abstract:
>   This document provides a YANG module for describing BGP communities.
> 
> The Internet-Draft can be found here:
> https://www.ietf.org/archive/id/draft-pels-grow-yang-bgp-communities-00.html
> 
> Please share with the mailing list if you would like this work to be
> adopted by GROW, are willing to review and/or otherwise contribute to
> this draft!
> 
> WG Adoption call ends January 6th, 2024.

I think it is an interesting approach to a real problem, and worthy of
group adoption.

An overall question I have is with so many nominally unstructured string
fields, does that just push the problem out further?  For example, in the
presentation at IETF, it was mentioned some communities are informational
and some are actions.  Should there be enumerated fields in the model
denoting this?  

Things in my mind to consider are not just throwing semi-structured data
out there for use cases like annotating looking glasses, but could this
also help with having a defined format that could help the
discoverability of actions for automation systems to use without a human
having to read through arbitrary string fields?   I realize this could be
daunting and potentially delay progress, but there are probably enough
usual suspects (like do-not-send-to-xxx and prepend-x-times, etc) that
they could be enumerated?

Having done some yang stuff on the provisioning end of things, I would
emphasize Tom Petch's note to consider typedef's already defined
whenever reasonable.  For example, RFC 6991 defines 'uri',
'email-address', 'as-number' (of course this will be 4-byte...).  There
may be more instances like this.

>From an ecosystem perspective, we should be thinking about where these
would get (linted and) published.  Or do we just settle on 
yang-o-rama.sobornost.net now. ;-)

Dale

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Working Group Call for draft-fiebig-grow-bgpopsecupd (start 06/Dec/2023 end 06/Jan/2024)

[Dale W. Carder]

Thus spake gengnan (gengnan=40huawei@dmarc.ietf.org) on Tue, Dec 12, 2023 
at 09:30:06AM +:
> Hi,
> 
> I support the adoption of the draft. Some comments that may need to be 
> considered: 
> 
> 1. The draft was proposed to GROW WG, but the wg info on the top of the first 
> page of the draft is opsec. 
> 
> 2. The meanings of "upstream" in this draft and the ASPA draft are different. 
> According to the term definition in this draft, the ASPA upstream 
> verification should be conducted for the routes from *downstream* or peer. 
> In section 3: "
> Upstream:
>   In a direct relationship between two ASes the one providing
>   upstream to the other.  (See: [RFC9234], also known as the
>   provider in a customer-provider relationship.)
> "
> In section 7.2.2: "
> In [I-D.ietf-sidrops-aspa-verification], see following sections based
>on the neighbor relationship:
> 
>*  Section 6.1 for routes received from upstreams and lateral peers.
> 
>*  Section 6.2 for routes received from downstreams and mutual-
>   transits.
> "
> 
> 3. The term "Mutual Upstream" is not used. It should be "mutual transit" or 
> "sibling". Also, some terms should be unified, e.g., "upstream" "upstream 
> provider"; "Internet peer" "lateral peer" "peer"; etc.
> 
> 4. In my understanding, some recommended operations have overlapped 
> protections/functions. For example, both OTC RFC 9234 and RPKI-ASPA can 
> detect route leaks. Should an operator deploy both techniques or just one of 
> them (under which conditions)?

Both!  See section 7.2 of draft-ietf-sidrops-aspa-verification

   While the ASPA-based AS_PATH verification method (Section 7.1)
   detects and mitigates route leaks that were created by preceding ASes
   listed in the AS_PATH, it lacks the ability to prevent route leaks
   from occuring at the local AS.  The use of the Only to Customer (OTC)
   Attribute [RFC9234] fills in that gap.


Dale

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow