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

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Gyan, thanks for your comments and feedback. Please find some responses inline. KV>

Kaliraj



Juniper Business Use Only
From: Idr <[e-mail]> on behalf of Gyan Mishra <[e-mail]>
Date: Tuesday, November 28, 2023 at 9:47 PM
To: Susan Hares <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Idr] WG adoption call - draft-kaliraj-idr-multinexthop-attribute-10 - (11/10/2023 to 11/24/2023)
[External Email. Be cautious of content]


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.

KV> Correct. Assuming the sender has arrived at the forwarding required at the receiver, MNH provides the encoding required to convey that information on-wire in a BGP route.

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.

KV> The capabilty has been removed in recent draft v-11, as it seemed to increase operational overhead and implementation complexity. The attribute is non-transitive, which helps in confining propagation scope.

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.

KV> Okay.

Cumulative Link BW Extended community
https://datatracker.ietf.org/doc/html/draft-ietf-bess-ebgp-dmz-03<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-ebgp-dmz-03__;!!NEt6yMaO-gk!H7B1f7ZAokpgdK2j2snKpdQJGPoAFEUS9ravCxwamZlQBSn8s6lCBOABlN45WV0f40dVq_EMoMuxFLvUwC6j$>


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.

KV> MNH does not convey the kind of tunnel to be used to reach each NH endpoints. Because that functionality is already performed by TEA.
KV> TEA can be used to describe any specific tunneling needs and properties to reach a NH endpoints.

VXLAN
https://datatracker.ietf.org/doc/html/rfc7348<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7348__;!!NEt6yMaO-gk!H7B1f7ZAokpgdK2j2snKpdQJGPoAFEUS9ravCxwamZlQBSn8s6lCBOABlN45WV0f40dVq_EMoMuxFBJI6ACo$>

EVPN UCMP
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb__;!!NEt6yMaO-gk!H7B1f7ZAokpgdK2j2snKpdQJGPoAFEUS9ravCxwamZlQBSn8s6lCBOABlN45WV0f40dVq_EMoMuxFEmXRiXU$>

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.

KV> yea, but MNH does not carry flow-label itself anywhere, as it is like entropy-label that is inserted by ingress. And for flow-label, I don’t think we need any negotiation
KV> at control plane layer, on whether ingress and egress support it, like the entropy-label case. If there was a need like that,  we could add a flow-label-capable flag in MNH.
KV> But its not required, AFAICT.

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 ?

KV> We plan to move the usecases to a new document, so we can give more details. And agree on mandatory/minimal-set part, will give more thought to it.

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.

KV> yea it is not encap per-se, it is just a way of signaling DSCP/QOS to a peer. The incoming data pkt can be decorated with either the signaled Encap or the DSCP codepoints
KV> to enjoy the forwarding-behavior (e.g. specific color tunnels) advertised by this route.

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?

KV> FwdAction type is “Forward” for routes with unlabeled nexthops. i.e. perform lookup and forward. this will push any encap that the lookup yielded.
KV> For routes with labeled nexthops, we can “Push” additional label/stack using this action.
KV> Actions 2-5 are mainly used with ‘Upstream-allocated MPLS-labels’, where the label allocator is off-box, and needs a way of expressing what forwarding it needs for the upstream allocated mpls-labels.
KV> Action 6 (Replicate) gives the multicast expression, for completeness.

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

KV> This is just the endpoint we need to forward to. Receiver of the route does NH-resolution for the EP, and uses the result to install the FIB.

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

KV> The ‘ProximityCheck’ constrain just gives better granularity of expressing whether a NH is singlehop/multihop, without having to make the BGP-session multihop/singlehop.
KV> The TransportClassID/Color constrain can be used to steer traffic over tunnels of that color, and yes this includes SRTE, RSVP-TE or other transport protocols that are color aware.
KV> basically, on a per NH level, we specify what color should be used.

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.

KV> the encap (e.g. Label) is imposed over the reachability to the EndpointId (e.g. NexthiopIPAddress). The EndpointId is the actual NH-address, that is
KV> parallel to the address carried in the NEXTHOP attribute today. Thanks.

Kind Regards

Gyan

On Thu, Nov 16, 2023 at 6:48 PM Gyan Mishra <[e-mail]<mailto:[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]<mailto:[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:

a.       Are there any errors or problems with this specification?
b.       Will this specification aid operational networks?

Cheerily, Sue Hares
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!H7B1f7ZAokpgdK2j2snKpdQJGPoAFEUS9ravCxwamZlQBSn8s6lCBOABlN45WV0f40dVq_EMoMuxFHTVm4_B$>