Subject: [IPsec] IP-TFS drafts calls.

From: Christian Hopps <[email-masked]>
Date: Tue, 5 Jan 2021 04:37:39 -0500

Hi,

Now that the IP-TFS draft has also completed its transport area review, can we start a WGLC on it?

  https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

Also, as per the last IETF meeting, can we please start an WG adoption call on the supporting YANG draft?

  https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/

Thanks,
Chris.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 17 Jan 2021 23:34:46 +0200

Christian Hopps writes:
> Also, as per the last IETF meeting, can we please start an WG
> adoption call on the supporting YANG draft? 
> 

I think this draft is not exactly in sync with the main iptfs, as it
still has some counters etc that would indicate there could be non
aggregated and aggregated packets mixed in same SA, and it says that
IP-TFS may be run only in one direction, but when using IKE I think
the IP-TFS is always for in both directions, but of course the
paramters and data rates might be different in different directions.

Also there is [email-masked] which looks like
typo, and it has this use-path-mtu, which does not tell which
algorithm is used etc.

Also I do not know what tx-drop-packets is supposed to mean? If we
have already sent them how can we find out information whether it was
dropped or not. Or is that supposed to be tx-queue-drop-packets, i.e.,
packets that were dropped before added to the outer ESP packet?

Also it is difficult to say whether some of the counters are counting
inner or outer packets, so it would be better to be more exact with
the wordings, i.e., in addition of using -inner- perhaps also use
-outer-.

Is there going to be update for this draft to get it in sync with the
main draft?
-- 
[email-masked]

---

From: Don Fedyk <[email-masked]>
Date: Mon, 18 Jan 2021 20:35:09 +0000

Hi Tero

For draft-fedyk-ipsecme-yang-iptfs-01 we are asking for adoption as WG draft which means it does not need to be perfect.  
The intention is supports the draft-ietf-ipsecme-iptfs-05 which is at a different stage and Chris is the sole author so I'll let him address. 

Please see the answers [don] inline:  

Thanks
Don

-----Original Message-----
Subject: [IPsec] IP-TFS drafts calls.

>   https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/

I think this draft is not exactly in sync with the main iptfs, as it still has some counters etc that would indicate there could be non aggregated and aggregated packets mixed in same SA, 
[don] We can clarify.  The stats are not per type of SA but only the relevant stats would be updated per SA. So yes it is in sync but some counters would be zero per SA. (my understanding). 

and it says that IP-TFS may be run only in one direction, but when using IKE I think the IP-TFS is always for in both directions, but of course the paramters and data rates might be different in different directions.

[don] We can clarify. The intention is IP-TFS encapsulation may not be operating in both directions.  

Also there is [email-masked] which looks like typo, and it has this use-path-mtu, which does not tell which algorithm is used etc.
[don] Not a typo The base draft draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 contains 3 related YANG models. 
[email-masked] 
[email-masked]
[email-masked]

We augment the ike and the ikless with use-path-mtu for the IP-TFS tunnel packet size computation.  
I think you may be referring to the sample configuration data. This data shows IP-TFS configuration samples only.  But encalg encryption algorithm is a configuration mandatory object in YANG schema we are augmenting.  Therefore we supplied a minimal configuration for this schema - enough to satisfy yanglint. 
We can add a note - this is common policy for test modules as far as I know.  The  draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 contains much more extensive sample configuration for the cases when encryption algorithm is specified. 

Also I do not know what tx-drop-packets is supposed to mean? If we have already sent them how can we find out information whether it was dropped or not. Or is that supposed to be tx-queue-drop-packets, i.e., packets that were dropped before added to the outer ESP packet?
[don] The description is Outbound dropped packets so your understanding is my understanding we have overrun the ability to transmit the packets either due to queuing or other.  We will clarify. 

Also it is difficult to say whether some of the counters are counting inner or outer packets, so it would be better to be more exact with the wordings, i.e., in addition of using -inner- perhaps also use -outer-.
[don] The current wording is inner for packets that are encapsulated. The ipsec-stats capture outer packets. (Outers is redundant at that level.   All pad packets are outer (within iptfs- we could make inter an outer more explicit. Whereas extra pad packets are inner. (I assume this what you would like clarified.

Is there going to be update for this draft to get it in sync with the main draft?
[don]It is in sync but we can clarify your points (and any other clarifications of course). 

Thanks
Don 
--
[email-masked]

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Christian Hopps <[email-masked]>
Date: Tue, 19 Jan 2021 08:54:18 -0500

> On Jan 17, 2021, at 4:34 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Christian Hopps writes:

[...]
Don replied to many of your points, a couple comments below from me:

>  and it has this use-path-mtu, which does not tell which
> algorithm is used etc.

Correct, this draft was published prior to the addition of PLMTUD to the base specification (from the tsvart review). We'll update this in the next revision.

> Is there going to be update for this draft to get it in sync with the

Yes, of course, we're just requesting WG adoption, presumably there will be reviews (like yours) and revisions to address them. :)

Thanks,
Chris.