Put in a PR to add LDP ordered control operation for LDP.

Put in a PR to add op commands for LDP.

Put in a PR to fix spelling/help string error. My bad. I didn't catch it before.

Put in a PR to add documentation for LDP import/export control again. I didn't rebase properly last time. Sorry everyone :(

Put in a PR to add LDP import/export control.

@bbs2web, here's what I got...

@bbs2web, getting this one (https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202012070521-amd64.iso) and will troubleshoot...

Put in a new PR to enable LDP local label allocation control.

This will be on my list to test here in a little bit. I'm almost done with stuff relating to LDP.

Put in a new PR to enable ethernet sub interface MPLS enablement. I screwed up the first one...but here's hoping this one is good.

Put in a PR to enable ethernet sub interface MPLS enablement

@bbs2web, I figured it out. I know what's not working.

I just did some testing, and @bbs2web, you're right. Sub interfaces to not get enabled. However main interfaces *DO* get enabled.

Try the new rolling by the way. There was a problem initially that we had to fix. Do like the rolling from 11/25 or tomorrow of 11/26.

@bbs2web, yessir, this is a new changed behavior. In the past when you configured an LDP interface it also enabled MPLS on the same interface.

Put in a PR for refactor of LDP template, MPLS python handler, addition of global MPLS parameters (via Linux kernel config changes), and separation of MPLS interfaces from LDP interfaces. *PLEASE* know I did do testing but I want more people to test as well. I have uploaded the package file for this PR here so that people can test my work.

@bbs2web, oh don't you worry. I've had my eyes on it after I get LDP done. I'm almost done with it too.

Put in a PR to add miscellaneous MPLS and LDP parameters.

Put in a PR to add targeted LDP neighbors.

Sure, no worries. We still have a *ton* of work on 7.3.1 to do so I'm sure we'll get to 7.5 in time :)

Not sure if it's relevant or not, but I think 7.5 was released....we might be able to just leapfrog 7.4 and go directly to 7.5 instead.

Put in a PR to add session hold time for static LDP neighbors.

Put in a PR to add TTL security for static LDP neighbors.

Put in a PR to separate hello/hold timers for IPv4 and IPv6. Added IPv6 timers.

I put a request on this up top. We'll get to it eventually, but I was hoping we could put it like this:

Here is the test for the LDP session time change.

Here is the test for Explicit Null.

Everything seems to be good. Closing case.

Submitted second PR

Submitted PR

I'll be giving those a test once T2981 is done. I'll report back here with results :)

PR is added here...

The last thing I think we can add is the dual stack capability options. We only got 2.

Ok, so here's the import LDP FEC one that I think we could take advantage of as well.

Ok, so here's the export LDP FEC one that I think we could take advantage of.

The one after that I feel would be fairly easy to also implement is customized label allocation. Again, it is under the family of IPv4 or IPv6.

The next one that I think would be fairly easy to add would be the following:

Hello sir. I am unsure if you're able to add more under LDP but I have found others if you possibly could add. They should be simple additions and are already supported under FRR 7.3.1.

The way I was thinking is on this Juniper page here.

In T2898#75677, @jack9603301 wrote:

@Cheeze_It

I also take into account the specific situation of the ndp proxy, the configuration of this link prompts, the configuration format of the ndp proxy is like this.

https://manpages.debian.org/buster/ndppd/ndppd.conf.5.en.html

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

@Viacheslav, I am unsure if you're able to finish the template and/or work on it more but if you guys ever choose to complete it and add it into rolling then I can test it out in my lab.

Not quite sure if this is the right thing to do but, if a "delete protocols ospf" command is given the equivalent in FRR should be "no router ospf".

If you guys want, I can also try to test it out too...

@adestis yes, that is true....but that can be worked around. Any option can be used (either BFD, or ARP, or ICMP). I just wanted to give more ideas so that hopefully can get a working implementation for all 3.

@Viacheslav, when I try that I get the following:

Version of Vyos I have is:

Ok, I got the new version of code and here is what I found. As a baseline here's the Vyos config, and it's more or less the same as before but I moved lab environments:

Would it be reasonable to use BFD for this? Since BFD is already implemented we might be able to use that as well?

In T915#73449, @Viacheslav wrote:

PR https://github.com/vyos/vyos-1x/pull/531
Add discovery hello timers

In T915#73395, @Viacheslav wrote:

@Cheeze_It Thank's. Can you describe what features you are missing?
And if possible, an example configuration.

I also want to add more verification. I was able to bring up LDP *properly* to a Juniper as well. The one thing I was not able to 100% verify was that the labels themselves were proper from end to end *BUT* the Junipers did properly see the labels and did allocate from Vyos. Vyos itself also did the same. Due to a lack of ability to specify an explicit null I cannot absolutely verify yet, but I hope to be able to in the future. SO far though it seems that you guys have done a good job making sure that the P functionality works, and label allocation works. Well done. I was *ALSO* able to make the MPLS label pop up properly. Please check the very bottom for the verification of it working :)

In theory, service providers use OSPF and ISIS for IGPs. LDP in theory shouldn't really care which protocol is used for the next hop as long as the next hop resolves and the label is there for the next hop for that LSP. Albeit I will admit I am not sure how it is organized in FRR. OSPF and ISIS should both be able to work though for next hops, and they should be consistent.