Re: [Idr] Regd. https://datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/

["Satya Mohanty (satyamoh)" <[e-mail]>]

Hi Kaliraj,

Thanks for your email. Please find my response inline, [Satya]

From: Kaliraj Vairavakkalai <kaliraj=[e-mail]>
Date: Saturday, August 12, 2023 at 1:07 AM
To: Satya Mohanty (satyamoh) <[e-mail]>, Dongjie (Jimmy) <[e-mail]>, [e-mail] <[e-mail]>, MEANS, ISRAEL L <[e-mail]>, RAMADENU, PRAVEEN <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Idr] Regd. https://datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/
Satya,

>)  Suggestion was given to use another label mode i.e., per-prefix (per-vrf does not apply here).

Perhaps it may help to clarify explicitly why per-vrf does not apply,
to both scenarios in PD#1<https://www.ietf.org/archive/id/draft-mohanty-idr-secondary-label-00.html#section-4.1> and PD#2<https://www.ietf.org/archive/id/draft-mohanty-idr-secondary-label-00.html#section-4.2>.
[Satya] This is because the routes in question are L3VPN routes (SAFI 128) in the default VRF context which are subject to a next-hop self. So, the only modes that apply are per-prefix or per-nexthop-received-label; the same reason why only per-prefix/per-nexthop-received-label label allocation mode is valid at an Option-B ASBR. Hope that clarifies.

Also, another question I have is: why the constructs used for PD#1 does
not work for PD#2 as-well?
[Satya] Construct is similar (Both cases need a secondary label)  but context is very different in the two cases. In PD#1, the context for local label allocation depends on the secondary label received from the peer. In PD#2 case, we do not have that assumption, and the use-case is PIC in case of a dual link scenario. To distinguish these two use-cases, we found it useful to have a type-specifier in the attribute (Section 6, Figure 3).

I’ve thought about such scenarios in MNH<https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-09#appendix-A.9> draft (that you mention in PD#1 context),
I think the same construct should apply for PD#2 as-well.
[Satya]  I suppose it could . However, as we have mentioned while referring to the MNH work in the draft, we did not need next-hops etc. factored into the attribute i.e., all the bells and whistles of the MNH draft) for the use-cases described here.
After a PE1-ISP1 link failure, as long as the repaired traffic arriving at PE2 from PE1
is coming with a label, whose route at PE2 does not have a nexthop leg pointing back to
PE1, that should avoid the traffic forwarding loop.
[Satya] Essentially yes with an added restriction.  What we have here ensures that so long as at least one of PE1-ISP1 and PE2-ISP1 link is up, traffic ingressing on PE1 and PE2 will always prefer ISP1 as exit point to go to the customer. If traffic is ingressing at PE1 and then PE1-ISP1 link goes down, the “repaired traffic” that you mention above will be diverted to PE2, but it is not enough for PE2 to send it to ISP2 to avoid the loop. It should forward to ISP1 if the PE2-ISP1 link is up and forward on the tertiary path over the PE2-ISP2 link if and only if PE2-1SP1 link is down. As you can observe the secondary label on PE2 (with primary nexthop pointing to ISP1 and backup pointing to ISP2) and propagated via BGP achieves exactly this behavior.

Thanks
Kaliraj

Thanks.

Best,
-Satya

Juniper Business Use Only
From: Idr <[e-mail]> on behalf of Satya Mohanty (satyamoh) <satyamoh=[e-mail]>
Date: Thursday, July 27, 2023 at 12:36 AM
To: Dongjie (Jimmy) <jie.dong=[e-mail]>, [e-mail] <[e-mail]>, MEANS, ISRAEL L <[e-mail]>, RAMADENU, PRAVEEN <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Idr] Regd. https://datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/
[External Email. Be cautious of content]

Hi Keyur and the chairs,

Towards the end of my IETF presentation, the audio was coming garbled at my end and not at all coherent.
I went over the recording today. I am replying to the two questions/observations.

1)  Suggestion was given to use another label mode i.e., per-prefix (per-vrf does not apply here).  However, using per-prefix label allocation would result in the inline RRs/ASBRs exhausting their label threshold (platform dependent  very quickly as the route scale increases (platform dependent upper-limit). Therefore, using per-prefix label allocation was ruled out in this deployment after being given due consideration.

Cisco IOS-XR supports the per-nexthop-recvd-label mode for some-time now in Option-B ASBR and RR with nh-self use-cases, precisely for this reason.  I believe other vendors has an equivalent mode. Idea is to take advantage of the optimal label allocation by this mode and simultaneously ensure fast convergence via BGP PIC.

2) Regarding the suggestion of not using the proposed attribute, the original thought was to use tunnel-encaps attribute. The problem that I saw is that the tunnel-encaps can have many sub-tlvs for different purposes, and if we wanted to restrict the advertisement of the secondary label to routers that do not need it, it will not be that easy as those same routers may need some other TLVs present in that same tunnel-encaps attribute. But, we do look forward to getting your inputs/suggestions on this as you indicated.

Thanks.

Best Regards,
--Satya



From: Idr <[e-mail]> on behalf of Satya Mohanty (satyamoh) <satyamoh=[e-mail]>
Date: Tuesday, July 11, 2023 at 9:44 PM
To: Dongjie (Jimmy) <jie.dong=[e-mail]>, [e-mail] <[e-mail]>, MEANS, ISRAEL L <[e-mail]>, RAMADENU, PRAVEEN <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Idr] Call for IETF 117 IDR agenda items
Hi Jie,

We would like to request a slot of 10 minutes to present the following draft. Tuesday slot is preferable.
https://datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mohanty-idr-secondary-label/__;!!NEt6yMaO-gk!DaZXd0sYsFJ37OdJZ1gn2Mpnjt7wudsvJ47pN1kVDsKn6dSgI5mayf81fOT0YlrYyMycFFG7lq2IQ0Am-cU5U2Vdz_IDOAAE$>

Thanks,
--Satya

From: Idr <[e-mail]> on behalf of Dongjie (Jimmy) <jie.dong=[e-mail]>
Date: Tuesday, June 27, 2023 at 3:57 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Idr] Call for IETF 117 IDR agenda items
Dear all,

The draft agenda of IETF 117 is available at https://datatracker.ietf.org/meeting/117/agenda<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/117/agenda__;!!NEt6yMaO-gk!DaZXd0sYsFJ37OdJZ1gn2Mpnjt7wudsvJ47pN1kVDsKn6dSgI5mayf81fOT0YlrYyMycFFG7lq2IQ0Am-cU5U2Vdz0lADQCK$>. The IDR sessions are scheduled as below:

- Monday Session II  13:00 - 15:00 (local time)  Plaza B

- Thursday Session IV 17:00 – 18:00 (local time)  Continental 4

Please start to send any IDR agenda item request to me and CC the chairs ([e-mail]). Please include the name of the person who will be presenting, and the estimate time you'll need (including Q/A).

If you plan to make a presentation, please keep in mind the IDR tradition, "no Internet Draft - no time slot". You should also plan to send your slides to me and CC the chairs no later than 24 hours prior to the IDR session, though earlier is better. Please number your slides for the benefit of remote attendees. By default your slides will be converted to PDF and presented from the PDF.

Potential presenters may want to take a look at the checklist for presenting at IDR:

https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%20at%20an%20IDR%20meeting

Best regards,
Jie