Re: [Idr] Doubt noticed while looking at draft-uttaro-idr-bgp-oad-02.txt

[Gyan Mishra <[e-mail]>]

I can see the very slight benefits for cooperating ASNs under the same
administrative domain, however this is a MAJOR quite massive  update to RFC
4271 as  to how BGP was intended to work as far as what path attributes are
transitive verses non transitive.

Taking a step back if you look at the gains for cooperating ASNs within the
same domain versus the massive change in BGP path selection process for the
entire internet, I am not sure this is a good idea.

Even within the same cooperating domain all operators and network
designers, every engineer out there worldwide  knows how BGP works today
and this is a complete rewrite of BGP following a brand new set of rules
for best path selection.

I am fearful of possible loops and routing issues that could arise with
such a dramatic change.

I think it would be good to test feasibility with some open BGP
implementations and test to see if there are any major problems that come
about before progressing.  This could be in a large virtual lab simulating
the internet and with OAD and try to make things break to see if the change
to the best path selection process causes any major problems.

There are a few path attributes I see that could benefit from the change
but there are already other path attributes that provide the same de
preference of backup paths capabilities or any other policy type changes.

If it’s not broken, don’t try to fix it.  I think that mantra applies to
this type of change to BGP.

I truly don’t think the benefits outweigh the risk.

As well as the possible implementation bugs that could crop up.  OMG!  I
hope I am retired before then.

Gyan
On Mon, Jul 10, 2023 at 4:25 PM Robert Raszuk <[e-mail]> wrote:

> Hi,
>
> The subject draft says:
>
> *3.3. NEXT_HOP*
>
>
> *The NEXT_HOP attribute is a well-known mandatory BGP path attribute
> [RFC4271] that MUST be present in UPDATE messages sent over EBGP-OAD
> sessions. The origination and modification of the NEXT_HOP attribute MUST
> comply with the EBGP-related specification in [RFC4271].*
>
> Well I am afraid this is wrong on multiple grounds.
>
> The reason to state this is that RFC4760 made NEXT_HOP attribute optional.
> It is no longer mandatory as next hop information is carried in
> MP_REACH_NLRI attribute.
>
> Moreover most protocol enhancements and in fact all which seems applicable
> to the author's goal went into defining NEXT_HOP information encoded in
> MP_REACH and not carried in standalone attributes.
>
> In fact RFC7606 very clearly highlights how NEXT_HOP path attribute became
> optional if we negotiate MP capability in section 3d:
>
>
>
>
> *   d.  If any of the well-known mandatory attributes are not present in
>      an UPDATE message, then "treat-as-withdraw" MUST be used.  (Note
>  that [RFC4760] reclassifies NEXT_HOP as what is effectively
>  discretionary.)*
>
> Observing the history there is still confusion among vendors and customers
> if standalone NEXT-HOP Attribute should be still sent in spite of MP
> capability or not.
>
> However it is clear that it would not be a great idea to suddenly make it
> mandatory for BGP-OAD.
>
> Thx,
> R.
>
> PS. Yes, its mandatory nature as defined in RFC4271 was never formally
> relaxed. But it really does not make any sense to send the same information
> twice ... and it makes UPDATES much more fragile if they happen to contain
> different data formats.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*