Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

Hi, I support adoption and the charter addition.  (No surprise as I'm a contributor to this work.) Also, I know of no IPR that applies to this draft. Lou On 10/26/2019 11:17 AM, Tero Kivinen wrote: So this is fast (one week) adoption call for the draft-hopps-ipsecme-iptfs draft to be accept

Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number.

On 6/8/2020 7:05 AM, Steffen Klassert wrote: On Sun, Jun 07, 2020 at 09:43:41PM -0400, Michael Richardson wrote: Steffen Klassert wrote: > This alterative usecase tries to solve the 'small packet' tunneling > problem. Sending small packets over a tunnel usually creates quite a

Re: [IPsec] Early Allocation Request for IPTFS_PROTOCOL IP protocol number.

I really think it makes most sense to push put in the early allocation request.  This is a valid long term use case.  There's no real shortage of IP numbers and IANA is continuing to assign them.  Also there's also a slew of them that can be reclaimed if/when they do become scarce.  I can even

Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

This is a sub-optimal compromise b/c all IPsec have SA databases even ones running IKE -- i.e., SA databases are common whether exposed in YANG or not -- but if it can move it forward perhaps good enough. Speaking as an interested party, I hope that some compromise / good enough solution is fo

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Valery, Please see below. On 10/13/2020 3:22 AM, Valery Smyslov wrote: Hi Chris, Hi ipsecme and chairs, This is a small update to the IPTFS draft which incorporates the last 2 changes that had been requested over the last year or so. 1. As requested last year, it dispenses with the late-en

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

I can live with MAY. On 10/13/2020 9:16 AM, Valery Smyslov wrote: If you badly need this feature, then please make it MAY and negotiable, so that people can ignore it. SHOULD is too strong for it, leaving it non-negotiable is just unacceptable, IMHO. ___

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Valery, How about this: OLD    Receive-side operation of IP-TFS does not require any per-SA    configuration on the receiver; as such, an IP-TFS implementation    SHOULD support the option of switching to IP-TFS receive-side    operation on receipt of the first IP-TFS payload. NEW    Receive-si

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Valery, >    If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place. I read this added line as saying you can switch from tunnel to TFS, I think you mean that use of TFS is controlled via IKE.  How about?    If IKE is used to negotiate using IP-TFS, then use of TF

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Hi Tero, see below On 10/13/2020 1:32 PM, Tero Kivinen wrote: Lou Berger writes: Valery, How about this: OLD    Receive-side operation of IP-TFS does not require any per-SA    configuration on the receiver; as such, an IP-TFS implementation    SHOULD support the option of switching to IP

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Tero,     are you saying you not happy with the proposed text as discussed with valery? Thanks, Lou On 10/13/2020 5:00 PM, Tero Kivinen wrote: Lou Berger writes: I have to admit that I have not read this draft, but noting, that most of the cipher we use do require automated key management

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Thanks Valery.  Based on the subsequent discussions, I suspect it may be best to just drop the whole section/capability.  So much for postel's law... Lou On 10/14/2020 2:26 AM, Valery Smyslov wrote: Hi Lou, Valery, >    If IKE is used to negotiate using IP-TFS, then such switching MUST NOT

Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

On 10/15/20 5:20 PM, Christian Hopps wrote: I do not think there is IP protocol number for IPv5, but if you really want to have protocol number, why not use 253 that is reserved for experimientation and testing. There is it's officially called "Internet Stream Protocol". Lou could speak more a

Re: [IPsec] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-09.txt

On 10/16/2020 4:19 AM, Rafa Marin-Lopez wrote: > If there is no objection, we can include this feature adding a > description about the motivation behind this and prepare v10 very quickly. Thank you for this. I think it would be a really helpful change -- and I support it. Lou (as cont

Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs

Hi Valery, I think you make a number of good mechanism specific technical points that are worth addressing in the document, but I think that recasting/redirecting this work goes too far.  This work has always been focused on a specific application (TFS) and it's utility beyond that applicatio

Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs

I think yang definition is a necessary compliment of draft-ietf-ipsecme-iptfs, so support the adoption of this document. On 1/24/2021 8:59 PM, Tero Kivinen wrote: This is the start of 3 week WG adoption call for this document, ending 2021-02-15. Please send your reply about whether you support

Re: [IPsec] iptfs publication request

I'd prefer to see the SHOULD and MAY reversed -- intentionally introducing additional reordering is generally considered something to avoid.  I'd also be fine with both being a MAY and a recommendation for this to be configurable. Lou On 10/31/2021 3:53 PM, Michael Richardson wrote: Tero Kiv

Re: [IPsec] iptfs publication request

Hi Tero, see below On 11/5/2021 3:09 PM, Tero Kivinen wrote: Lou Berger writes: I'd prefer to see the SHOULD and MAY reversed -- intentionally introducing additional reordering is generally considered something to avoid. Yes, intentionally introducing reordering or delay SHOULD be av

Re: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt

Hi Tero, You said: On 11/9/2021 5:11 AM, Tero Kivinen wrote: I think there is still bit of tweaking that can be done, Is this tweak being made as a blocking comment by the document Shepherd or a non-blocking comment as a contributor? If it's a blocking comment -- Sure let's make whatever c

Re: [IPsec] Agenda for IPsecME @ IETF#113

Tero/Ben, Is there any word on what's happening with the TFS drafts? They've been in the IESG queue for a while now. Thanks, Lou On 3/16/2022 9:06 AM, Tero Kivinen wrote: IP Security Maintenance and Extensions (IPsecME) WG. IETF 113 - Friday March 25th, 2022 11:30-13:30:00 UTC, 12:30-14:30

Re: [IPsec] Agenda for IPsecME @ IETF#113

en On Thu, Mar 17, 2022 at 02:36:23PM -0400, Lou Berger wrote: Tero/Ben, Is there any word on what's happening with the TFS drafts? They've been in the IESG queue for a while now. Thanks, Lou On 3/16/2022 9:06 AM, Tero Kivinen wrote: IP Security Maintenance and Extensions (IP

[IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

Authors, As I mentioned in last week's meeting, I have some comments on this document from the routing perspective. I don't think these are major, but I still think they should be addressed. In section 1.1, you define the term gateway. I'm assuming that you are using the term in the normal IPse

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

Vishwas, Thanks for the quick response. Please see below. On 11/15/2012 7:14 PM, Vishwas Manral wrote: > Hi Lou, > > Thanks a lot for your detailed comments. I have just started to change > the document today, based on feedback I got on the list, so your > comments come at a good time. M

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

Vishwas, Please see below. On 11/16/2012 12:49 PM, Vishwas Manral wrote: > Hi Lou, > > Thanks for the quick reply. Just a few comments prefixed with a "VM>": > > > > > We can add something in the lines of additional protocols are run over > > the IPsec tunnels and the solution shoul

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

passes the packet on. > > Where do we see the need for tighter integration here? Is it allowing > the ability to create groups of ADVPN instances? > > Thanks, > Vishwas > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger <mailto:lber...@labn.net>> wrote: >

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

w about something like: X. The solution MUST support Provider Edge (PE) based VPNs. Note that this phrasing doesn't indicate a specific solutions which is why I now suggest "MUST" vs "SHOULD". Lou > > Thanks, > Vishwas > > On Fri, Nov 16, 2012

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

phrasing doesn't indicate a specific solutions which is > why I now suggest "MUST" vs "SHOULD". > > Lou > > > > > Thanks, > > Vishwas > > > > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <mailto:lber..

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

from the WG on this, if they have any opinion. If > not we can go ahead with your suggestion. > > -Vishwas > > > On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger <mailto:lber...@labn.net>> wrote: > > Vishwas, > > On 11/16/20

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

n works for the star, full mesh as well as dynamic full mesh topology. This revision now reads that the primary reason for dynamic spoke-to-spoke tunnels is separate management domains. I somehow don't think this was the intent. In section 4.1 we had discussed replacement text for 3: On

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

ement domains. I somehow don't > think this was the intent. > > > I have reordered the sentences. I think that works. > > > In section 4.1 we had discussed replacement text for 3: > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > >>On 11/15

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are run over IPsec tunnels, and the configuration impact on those protocols must be considered. There is also the case when L3VPNs operate over IPsec Tunnels. > > > > > > > >

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

Vishwas, I think I see where you're headed. The text under discussion is: Routing using the tunnels SHOULD work seamlessly without any updates to the higher level application configuration i.e. OSPF configuration, when the tunnel parameter changes. I read this a requirement being

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

raft, with all your comments incorporated. > > I will post the draft soon. > > Thanks, > Vishwas > > > > On Thu, Dec 6, 2012 at 11:15 AM, Lou Berger <mailto:lber...@labn.net>> wrote: > > >

Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem

Excellent & thank you! Lou On 12/7/2012 12:51 PM, Vishwas Manral wrote: > Updated. Will post the document across. > > -Vishwas > > On Fri, Dec 7, 2012 at 6:20 AM, Lou Berger <mailto:lber...@labn.net>> wrote: > > The ADVPN solution SHOULD NOT

Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

Vishwas / Brian, See below On 12/13/2012 12:54 PM, Vishwas Manral wrote: > Hi Brian, > > Thanks a lot for your comments and sorry I did not reply immediately. I > have still been waiting for the version 2 to upload. I have sent it to > the internet-dra...@ietf.org

Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

Brian, Opps, should have replied to this message (and not the prior). My previous mail basically said the new requirement is placed on the ADVPN solution, not a particular implementation. I think it's important to ensure that the overall solution provides for Requirement 14, and I'm not s

Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

=== > On Fri, Dec 14, 2012 at 1:56 PM, Brian Weis <mailto:b...@cisco.com>> wrote: > > Hi Lou, > > On Dec 14, 2012, at 10:15 AM, Lou Berger <mailto:lber...@labn.net>> wrote: > > > Brian, > > Opps, should ha

Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

Brian, Just want to confirm that Vishwas solution closes this issue. Agreed? Thanks, Lou On 12/14/2012 4:56 PM, Brian Weis wrote: > Hi Lou, > > On Dec 14, 2012, at 10:15 AM, Lou Berger wrote: > >> Brian, >> Opps, should have replied to this message (and

Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

excellent. Thank you both for resolving my comments so rapidly! Lou On 12/17/2012 1:43 PM, Brian Weis wrote: > > On Dec 16, 2012, at 9:12 AM, Lou Berger wrote: > >> Brian, >> Just want to confirm that Vishwas solution closes this issue. Agreed? > > A

[IPsec] Some comments on draft-detienne-dmvpn-00

Hi, I have the following comments/questions on the draft: - Why allow IPsec tunnel mode? Is there a case where it provides some value? - Do you want to recommend omitting the GRE checksum? - I think the draft should discuss what happens when the best route moves from one spoke to another

Re: [IPsec] Some comments on draft-detienne-dmvpn-00

mer Advocacy CISCO > > > >> -Original Message- >> From: Lou Berger [mailto:lber...@labn.net] >> Sent: Friday, October 18, 2013 3:29 PM >> To: draft-detienne-dm...@tools.ietf.org >> Cc: IPsecme WG >> Subject: Some comments on draft-detienne-dmvpn-00 >> &g

Re: [IPsec] Some comments on draft-detienne-dmvpn-00

; -----Original Message- >> From: Lou Berger [mailto:lber...@labn.net] >> Sent: Thursday, October 24, 2013 8:57 AM >> To: Mike Sullenberger (mls) >> Cc: IPsecme WG; draft-detienne-dm...@tools.ietf.org >> Subject: Re: [IPsec] Some comments on draft-detienne