Re: [Idr] WG adoption call - draft-kaliraj-idr-multinexthop-attribute-10 - (11/10/2023 to 11/24/2023)

[Gyan Mishra <[e-mail]>]

Hi Kaliraj

After reading through all the comments on ML, I see MNH as a N-Way ECMP /
UCMP handling intelligence based forwarding paradigm shift possible control
plane optimization that allows all the paths to be adversed for a prefix in
a single BGP update containing all the MNH legs with its pecking order
prioritization sequencing of NH for ultra granular UCMP load balancing
characteristics.

The path attribute by itself could have been sufficient but adding the
capability code point I am guessing the reason for that is further P2P
peering control of the propagation of the path attribute?  Or maybe some
other reasons.  In that respect is similar to add paths P2P code point
implementation.

I can see this having great benefits in BGP Only DC dense clos fabric with
dense n-way paths that need prioritization.  This can be used for MPLS,
SR-MPLS or SRv6 BGP Only DC alternative to existing options.

Cumulative Link BW Extended community
https://datatracker.ietf.org/doc/html/draft-ietf-bess-ebgp-dmz-03


For DC NVO overlays VXLAN, GENEVE   we have other options for load
balancing options  “source port entropy” today and I wonder how MNH would
come into play.   I think MNH could still be used proving a update packing
optimization with the MNH next hop leg n-way ECMP paths and provide the
detailed TLV info for other optimizations to optimize traffic flow
characteristics.

VXLAN
https://datatracker.ietf.org/doc/html/rfc7348

EVPN UCMP
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb

SRv6 uses IPv6 data plane so uses IPv6 flow label RFC 6437  for n-way ECMP
uniform load balancing.  Here I can see MNH providing UCMP capabilities at
the BGP control plane layer.

I think in the draft it would be a great idea to add some use cases as the
ones I have mentioned.   I think what would help is adding use cases for
use cases for the variety of TLVs and how they would be used individually
or in conjunction with other TLVs or even all of them together. There is a
lot of information carried in the TLVs for forwarding semantics and is all
the information absolutely necessary is a good ?

Few comments on the MNH TLV types

Encapsulation type ?
So we have 3 data plane that exist today which are MPLS, IPv4, IPv6

Of which we have 2 forwarding planes
SR-MPLS - reuses MPLS data plane
SRv6 - reuses IPv6 data plane

I am not sure why DSCP would be encapsulation type however I think it’s
referring to QOS as part of above data planes.

So of the data planes / forwarding planes  you can have MPLS / SR-MPLS and
IPv6 / SRv6 or MPLS in parallel in a network.  So I agree those are the 3
possibilities but think DSCP seems out of place.
So the idea is you could forward to MNH based on data plane / forwarding
plane semantics different next hop data plane / forwarding plane.  Makes
sense.

Forwarding action type
So the forwarding actions are based on what is configured for label
allocation mode per prefix, per ce, per VRF for PE-CE label imposition and
disposition function.  For 2-5 MPLS actions those would happen based on
label allocation mode.  So how would that come into play in forwarding
decision?

Forwarding argument
Endpoint identifier
So how does this come into play to influence routing decision and / or
forwarding?

For path constraint can that be used in some way with SR policy service
route color to SR policy  intent mapping for steering instantiation?

Would be interesting to see an example of how that would work.

The endpoint identifier matches the encapsulation type data plane /
forwarding plane so am not sure what additional value is provided by
endpoint identifier.


Kind Regards

Gyan

On Thu, Nov 16, 2023 at 6:48 PM Gyan Mishra <[e-mail]> wrote:

>
> I support WG adoption of MNH draft.
>
> I do not see any errors or issues with the draft.
>
> A possible use case for MNH could be for cases with global table routing
> in an RR network where it is not desired for the RR to perform the best
> path calculation based on its IGP distance to exit point and as well not
> desirable to flood all paths using RFC 7911 add paths and requiring the RR
> to use knob to subsequently select and advertise and flood all paths to all
> PEs.  In that particular use case of hot potato Routing can be overcome by
> ORR optimal route reflection, however now MNH can accomplish this task
> nicely.
>
> Another use case in RFC 4364 MPLS IP VPN networks where it’s desired to
> use the global RD on all PEs and not use a unique RD in a RR based
> network.  In this particular case the RR is not able to reflect all the
> paths due to all paths having the same RD as the paths are reflected based
> on unique RD by the RR all paths are not propagated.  The MNH solution
> could provide a nice alternative to reflect all the paths without having to
> rely on add paths RFC 7912 and the propagation of paths maybe be in a more
> controlled fashion.
>
> There maybe as well load balancing use cases ECMP or UCMP that could take
> advantage of MNH.
>
> Kind Regards
>
> Gyan
>
> On Fri, Nov 10, 2023 at 4:19 AM Susan Hares <[e-mail]> wrote:
>
>> This begins a WG adoption call for
>> draft-kaliraj-idr-multinexthop-attribute-10.txt.
>>
>>
>>
>> Each author should reply to this message with a message
>>
>> that indicates whether you know of any IPR on this topic.
>>
>>
>>
>> During your consideration,  please consider:
>>
>>
>>
>>    1. Are there any errors or problems with this specification?
>>    2. Will this specification aid operational networks?
>>
>>
>>
>> Cheerily, Sue Hares
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>