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. Christian Hopps writes: > 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/ 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 ietf-i2nsf-ikel...@20202-10-30.yang 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. ietf-i2nsf-ikel...@20202-10-30.yang ietf-i2nsf-i...@2020-10-30.yang ietf-i2nsf-...@2020-10-30.yang 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 -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
