Re: [Idr] Yangdoctors early review of draft-ietf-idr-bgp-model-09

[tom petch <[e-mail]>]

________________________________________
From: Idr <[e-mail]> on behalf of Jeffrey Haas <[e-mail]>
Sent: 03 November 2020 00:43
To: Acee Lindem; Mahesh Jethanandani
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Idr] Yangdoctors early review of draft-ietf-idr-bgp-model-09

Acee,


On Tue, Oct 27, 2020 at 03:05:06PM -0700, Mahesh Jethanandani wrote:
> >     3. Page 25, "case ipsec": What is the reference for usage of transport
> >        mode IPsec with BGP? Please elaborate in description.
>
> I see release notes from vendors on IPsec for BGP, but no references that I can cite. Did you have something specific in mind?

There is no reference here.  Multiple BGP implentations support running BGP
over an ipsec tunnel.  A previous prod during a prior review suggested that
if we had something to use from an IETF group doing yang work on ipsec for
protecting routing transport sessions might be applicable here.
<tp>

Jeff

I2NSF have produced an I-D, currently with the IESG, on configuring IPsec.  It is part of I2NSF which is a lot more than IPsec but it did attract a comment from IPSECME WG asking that it be changed to make it more widely applicable with, I think, an implication that IPSECME might be about to do something.

IPsec, indeed IPSECME, is not my stock in trade, more like TSL and SSH but it did make me look at all those old IKEv2 RFC and wonder who used them:-)

Tom Petch

> >     5. Page 29, "remote-helper": I'd support this to be renamed
> >        "graceful-restart-only" since "helper-only" is relative to the local
> >     peer.
>
> The enumeration definitions talk about the mode in terms of local and remote. Calling it ‘graceful-restart-only’ conveys a completely different meaning.

There's actually a few issues here:
- The restarting mode is per AFI-SAFI, while this container doesn't contain
  anything that contains per AFI-SAFI state.
- The local peer can know whether it's acting as a helper and whether it can
  retain forwarding for a given AFI/SAFI.
- We can know if the remote BGP speaker has advertised GR for a given
  AFI/SAFI, which tells us whether it supports GR and can help the local
  speaker with restarting.
- We can know if, on the last restart, forwarding was preserved for that
  AFI/SAFI.

Proposal: Replace leaf "mode" with:
list afi-safi-supported {
  key "afi-safi-name"
  leaf afi-safi-name {
    type identityref { base bt:afi-safi-type; }
  }
  leaf local-supported {
    type boolean;
  }
  leaf remote-supported {
    config false;
    type boolean;
  }
  leaf remote-forweard-preserved {
    type boolean;
    config false;
  }
}



>
> >     6. Page 30, "fsm-established-transitions": What is the difference with
> >        "established-transitions"? Is the description a cut-n-paste error?
>
> I will rename “established-transitions” to “peer-fsm-established-transitions”.
>
> >     7. Page 33, "backward-transition": This implies any backward transition.
> >        I'd suggest renaming to "established-state-lost"
> >     or "established-backward-transition".
>
> But backward-transition is defined as when the BGP new status is lower than the last one, not just from established -> idle.

Note from BGP MIB history: The original BGP MIB provided a trap on every
backward transition.  This meant a very noisy set of traps for sessions that
were repeatedly trying to connect.  Many vendors implemented knobs to
restrict this solely to transitions out of established.

I'd suggest the working group consider what it wants here.  We don't have to
repeat the mistakes of the past on this one.

> >    15. Page 72, "bgp-ext-community-type": Many of these string patterns are
> >        defined in RFC 8294. Also, it would be good to add the syntax of the
> >     pattern you are representing in the description.
>
> I will let my co-authors to comment on this.

RFC 8294 is narrowly focused on supporting a small cluster of VPN extended
communities.  The extended communities feature carries a number of
additional things.  A recent example would include the RPKI origin
validation community.  Others would be communities defined for
link-bandwidth and the BGP flowspec action communities.

The complete registry is here:

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

The issue thus comes where the general purpose registry for communities that
weren't defined in RFC 8294.  A similar issue comes down to how do we
maintain this list and add to it as we extend BGP by adding new extended
communities?

I agree that we should not repeat the items in RFC 8294.

Won't we need the extended communities typedef to be maintained in an IANA
registry to allow easy extension?

Error: the option to set-ext-community doesn't take this list.
Error: We don't have a RIB ext-community oper list.

> >    20. Page 78, "bgp-set-med-type": Please describe the syntax of the pattern
> >        in the description.
>
> I will defer this to my co-authors.

Set med in implementations typically permits additive/subtractive MEDs.  This
permits operations such as "set med = med + 5".

Syntax issue: the implementation is typically "set med", "set med additive
<value>" or "set med-igp".  Thus the syntax that's additive is only
applicable in some of these cases.

I believe we'll hae to restructure this.

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr