Moved that to wishlist priority,
require further discussion

This require further discussion and clarification,
suspect that there are lot of caveats there

@Merijn can you check on latest nighlies?

@hiroyuki-sato is this applies to 1.2.x series?

Do we need to create sub-task per component?

@jhendryUK can you retest on latest ?

@jhendryUK we will need to retest this on latest builds

Hey Rob, can you check this,
if we confirm that is just about enabling it in systemd
you can move it to backlog and assign to @UnicronNL

Moving this to backlog and assigning to @UnicronNL

@UnicronNL moving this to backlog

@flash can you retest with latest builds?

@flash can you reproduce this on latest builds?

@UnicronNL @dmbaturin
moving this to backlog on 1.2.x

We require feedback from community on that!
@dmbaturin
@UnicronNL
@EwaldvanGeffen
Your input appreciated

@JulesT assigning this to you,
we can close this is if not reproducible

Anyone can confirm this behavior ?

Moved to backlog and assigned to you

Lowering priority and removing it from backlog
this require more testing and more info

@UnicronNL we collected here all info,
do you think we can move that to backlog?

@EwaldvanGeffen so how this end up?
should i pick it up from you?

Just to explain this context, usually MSS Clamping is required in PPPoE/ADSL endpoints due to PPP overhead, but for edge routers there is a non common use: DDoS mitigation clouds. They usually encapsulates IP transit inside GRE tunnel and since GRE does not have any alternative like MLPPP (Multi Line PPP) and MRRU (Maximum Receive Reconstructed Unit), the transit session MTU does need a MSS adjust to allow TCP to work well over mitigated clouds.

@UnicronNL can we fix this for 1.1.8 too?

Can someone provide more input on this,
should we implement something like that?

Guys, if you can provide extensive description with examples,
i can do poll on that

I simply symlinked it to work around the problem.

Hi Jules

Hi Line2.

is your fix already in 'vyos-999.201707272138-amd64.iso'? I get in this version:

I can support this idea. It's quite usual on other routers or firewalls to have global objects, you define once and use it in firewall, nat, policy routing...

I mean groups that would act as global variables.

There's a pull request against vyatta-op-vpn that implements all of this.

That's one way to get it done.
You can also support multiple regions by copying the uploaded AMI using aws ec2 copy-image if you like.
I left comments suggesting improvement by using awss own --query flag to extract the output instead of filtering through jq (thus reducing the need for yet another tool).
I gave instructions in the comment as much as I can without testing the specific command.

I created initial script for making AMI with importing VMDK. I think this way is more useful for multiple region support.
The commit is here: https://github.com/vyos/vyos-build/commit/3dc5653bbb8133f976e4603c8f78a5f6cf686405
What do you think?

sorry, but I don't follow your idea
can you elaborate?

The specification has been published as IETF standard: https://tools.ietf.org/html/rfc8092

@MustDie please assign task to me

Agenda can be found here:
https://docs.google.com/document/d/1Rfso-LPJtMwnTWAtSYE96cYxtdB6TErOyVdG1hsvoUA/edit?usp=sharing

Thanks for sharing @higebu