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

[Robert Raszuk <[e-mail]>]

Hi Gyan,

Glad to see you have the same opinion. But one point needs to be clarified
in your note.

Since the very beginning of BGP4 1771 and 4271 attribute
transitiveness flag never intended to indicate that a given attribute can
or can not be sent to a peer (in case of extended communities
transitiveness to a peering AS).

It only indicates what a BGP speaker is supposed to be doing with
unrecognized attributes. Pass it or not.

Then of course each attribute may define its own rules when it is expected
to be received over IBGP or EBGP sessions. MED or LOCAL PREF are examples
of that however that is different from the transitiveness bit in the
attribute header.

But your point remains valid, it is just for a little bit of a different
reason :).

For me it seems that this is a type of proposal with a lot of work for no
clear reason and huge risk. Furthermore lack of understanding the peers OAD
capabilities makes it single sided and therefore really a local policy
configuration.

Sure as said we could have a document (RFC/BCP) with definition of such a
policy template - nothing wrong with that.

Cheers,
Robert


On Wed, Jul 12, 2023 at 2:35 AM Gyan Mishra <[e-mail]> wrote:

>
> 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*
>
>