Re: [ippm] Progressing draft-ietf-ippm-ioam-conf-state

[[e-mail]]

Hi Frank,

Thanks for replying to my email during your holiday season.
Please see inline ("XM>>>").

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：FrankBrockners(fbrockne)
收件人：肖敏10093570;
抄送人：[e-mail];[e-mail];
日 期 ：2021年12月28日 23:21
主 题 ：RE: Re:[ippm] Progressing draft-ietf-ippm-ioam-conf-state
Hi Xiao Min,
Please see inline ("...FB")
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, 20 December 2021 03:01
> To: Frank Brockners (fbrockne) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re:[ippm] Progressing draft-ietf-ippm-ioam-conf-state
>
> Hi Frank,
>
> Thank you for the quick reply.
> I believe you've provided your answer to my question implicitly, however what I
> requested is a clear conclusion, on both the mailing list and the draft-ietf-ippm-
> ioam-deployment.
> If I understand you correctly this time, you meant that the IOAM deployment
> must include a centralized controller or network manager or similar,
..FB: Let me restate what I said below: The current IOAM drafts assume that IOAM is deployed in a limited domain (RFC8799), also called controlled domain, i.e., a deployment where an operator does have control over the nodes in the network and their configuration. IMHO the use of the term "controller" does not help the discussion, because "controller" means different things to different people. The key aspect is that in a limited/controlled domain, the operator has control over the nodes in the limited domain and their configuration.
XM>>> In a limited domain, the operator has control over the nodes in the limited domain and their configuration, doesn't mean there must be a network entity (e.g. controller or network manager or similar) which has control over the nodes in the limited domain and their configuration, is my understanding correct or not?
Wrt/ DEX: On top of the ability to control the nodes and their configuration, DEX requires you to have a solution in place which allows you to retrieve, ingest, process, and correlate per-packet IOAM data from every node in the limited domain. This requirement to retrieve, ingest, process, and correlate per-packet IOAM data from every node in the limited domain is specific to the DEX IOAM-Option-Type and not required by the other IOAM-Option-Types. For example, the two IOAM Trace-Option-Types automatically correlate the information from the different nodes by assembling the info in the node-list array while the packet traverses the network.
XM>>> This requirement to retrieve, ingest, process, and correlate per-packet IOAM data from every node in the limited domain is not required by some IOAM-Option-Types, that means there may be a limited domain that doesn't meet the requirement that there is a network entity (e.g. controller or network manager or similar) which has direct connection to every node, is my understanding correct or not?
What is required from my perspective for draft-ietf-ippm-ioam-conf-state, is a crisp definition of the target deployment environment draft-ietf-ippm-ioam-conf-state targets and the personas acting in that deployment environment. In a limited/controlled domain, we can assume that the operator knows the configuration of the nodes. The problem definition of draft-ietf-ippm-ioam-conf-state seems to be that "someone" who does not know the configuration of the nodes in the deployment environment wants to retrieve the configuration of the nodes.
XM>>> Let me give a simplified example of the target deployment environment and the personas acting in that deployment environment. Assuming that the limited domain is an IPv6 domain, specifically an enterprise campus using physical connections between devices (as described in section 4 of draft-ietf-ippm-ioam-data-17), the operator knows the configuration of every node within the enterprise campus, however there is no a network entity (e.g. controller or network manager or similar) that knows the configuration of every node. In order to deploy IOAM Pre-allocated Tracing, the operator instructs the IOAM encapsulating node to add IOAM header into data packets meeting a rule of DA+SA+Flow Label, through Command Line or SNMP or NETCONF or similar, the IOAM encapsulating node firstly does traceroute using DA+SA+Flow Label and secondly sends ICMPv6 Echo Request to every node discovered by traceroute, the IOAM transit and decapsulating nodes respond with ICMPv6 Echo Reply, and then the IOA
 M encapsulating node knows what the IOAM header looks like, e.g. including how many node data lists and how much space allocated for each node data list. Is this example clear or not?
Cheers, Frank
> then I have
> a hard time trying to understand why four types of IOAM are needed in section 4
> of draft-ietf-ippm-ioam-deployment
> (https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-
> deployment#section-4). IMHO only one type of IOAM is necessary and enough,
> that's Direct Export IOAM described in section 4.4, would you please explain
> elaborately?
>
> Best Regards,
> Xiao Min
> ------------------原始邮件------------------
> 发件人：FrankBrockners(fbrockne)
> 收件人：肖敏10093570;
> 抄送人：[e-mail];[e-mail];
> 日 期 ：2021年12月17日 17:47
> 主 题 ：RE: Re:[ippm] Progressing draft-ietf-ippm-ioam-conf-state Hi Xiao Min,
> per https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-
> 17#section-4, IOAM is focused on "limited domains" as defined in [RFC8799],
> which is per RFC 8799 the same as what is also referred to as a "controlled
> environment". Personally I understand "Controlled environment" as an
> environment where an operator does have control over the nodes in the
> network and their configuration, i.e., the operator has control over his nodes,
> knows what network elements he is dealing with and what the config of the
> nodes is. How this control is implemented - whether there is one or several
> "controllers" or "network managers" or similar - is an implementation detail
> IMHO.
> Cheers, Frank
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Friday, 17 December 2021 03:29
> > To: Frank Brockners (fbrockne) <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re:[ippm] Progressing draft-ietf-ippm-ioam-conf-state
> >
> > Hi Frank,
> >
> > Thanks for your thorough review and thoughtful comments.
> > I apologize if I misinterpreted your mind.
> > Considering that your holiday season is coming, before digging into
> > technical details, I suggest that we discuss the IOAM deployment environment
> first.
> > As you may have noticed while reading through
> > draft-ietf-ippm-ioam-conf- state-02, in the introduction section it
> > says "A centralized controller which owns the enabled IOAM
> > capabilities of each IOAM device could be used in some IOAM
> > deployments.  The IOAM encapsulating node can discover the enabled
> > IOAM capabilities infomation from the centralized controller, using,
> > for example, NETCONF/YANG, PCEP, or BGP.  In the IOAM deployment
> > scenario where there is no centralized controller, NETCONF/YANG or IGP may
> be used by the IOAM encapsulating node to discover these IOAM capabilities
> information."
> > I know you're the primary author of both IOAM-Data and IOAM-Deployment
> > documents, so I have a fundamental question to you: Is the above
> > statement correct or not?
> > More specifically, if you can confirm that "the IOAM deployment
> > scenario where there is no centralized controller" doesn't exist at
> > all, on both the mailing list and the IOAM-Deployment document, then I
> > suggest IPPM WG to abandon draft- ietf-ippm-ioam-conf-state, that
> > would save the energy of the whole wg including you and me.
> >
> > Best Regards,
> > Xiao Min
> > ------------------原始邮件------------------
> > 发件人：FrankBrockners(fbrockne)
> > 收件人：肖敏10093570;[e-mail];
> > 抄送人：Tommy Pauly;
> > 日 期 ：2021年12月16日 20:56
> > 主 题 ：RE: [ippm] Progressing draft-ietf-ippm-ioam-conf-state Hi Xiao
> > Min, Thanks for posting draft-ietf-ippm-ioam-conf-state-02. I read
> > through the updated version and looked at the diff to the 01 version
> > (https://www.ietf.org/rfcdiff?url1=draft-ietf-ippm-ioam-conf-state-
> > 01&url2=draft-ietf-ippm-ioam-conf-state-02). Different from what you
> > state below, I don't see any of my comments reflected.
> > The two main points I mentioned in the last WG meeting were about (a)
> > alignment with draft-ietf-ippm-ioam-yang and (b) enhancements to the
> > security section, reflecting that the protocol you are defining is a
> > network management protocol, and needs to be secured as such.
> > More specifically:
> > * Alignment with draft-ietf-ippm-ioam-yang:
> > The IPPM WG is in the process of defining a YANG module for IOAM:
> > draft-ietf- ippm-ioam-yang. We should have a single, comprehensive
> > model for config information for IOAM. That model can then be rendered
> > into different transports (be it JSON, XML, or yet another format - to
> > then be carried over a e.g. ICMP in your case). Right now
> > draft-ietf-ippm-ioam-conf-state heads down a path of defining a new
> > set of management objects - many are similar to what
> > draft-ietf-ippm-ioam-yang already defines, some they are less
> > comprehensive, some hint at additional information that
> > draft-ietf-ippm-ioam-yang does not cover yet: E.g.,  you define a
> > "Pre-allocated Tracing Capabilities Object" where
> > draft-ietf-ippm-ioam-yang  has a "Preallocated Tracing Profile"
> > defined. You define ingress interface fields, which is information,
> > which is more comprehensively defined by the ioam-filter grouping. You
> > define specific fields to describe the timestamp format used by a
> > node, which is information that should be  described as part of the
> > ioam-info container - and which is currently missing in draft-ietf-ippm-ioam-
> yang; point well taken :-). It is interesting to note that draft-ietf-ippm-ioam-
> conf-state does not even reference draft-ietf- ippm-ioam-yang.
> > From my perspective we should have one single data model for IOAM
> > configuration - and that is the YANG module defined in
> > draft-ietf-ippm-ioam- yang. Let's make sure that this model covers all
> > the information required to properly manage IOAM. Then
> > draft-ietf-ippm-ioam-conf-state would be solely focused on defining
> > how that YANG module (from draft-ietf-ippm-ioam-yang) would be rendered
> into e.g., ICMP as a carrier protocol.
> > * Security: Revision -02 does not seem to update the security section.
> > IMHO, section 6 on security considerations should be enhanced to
> > clearly articulate that we're dealing with very sensitive information.
> > Consider loaning from e.g.,
> > https://datatracker.ietf.org/doc/html/rfc6241#section-9. As part of
> > the discussion, it would be good to see an explanation where you'd
> > expect  draft- ietf-ippm-ioam-conf-state to be used. Given the
> > discussion in the Introduction section, you seem to assume an
> > environment that does not have a central network management station /
> > controller in place. Or in other terms, you seem to target a
> > deployment, which isn't a limited domain per RFC 8799. In that case, I
> > would expect that we have normative language that requires the use of strong
> authentication and encryption between the nodes (i.e., MUST use ICMP with AH
> and ESP..).
> > In addition to the above, I struggle to understand the "Operational
> > Guide" in section 4: Could you shed a bit more light on how you expect
> > things to work - and what a target deployment environment would look
> > like? It seems that you assume that you don't know the network nor the
> > destination addresses in your
> > network: Do you expect that you would do regular "ICMP echo sweeps" in
> > your network? Do you expect that, while doing the expanding ring
> > search, an ICMP time exceeded message would also carry the "IOAM
> > Capabilities Response Container Header", so that the capabilities
> > container would not only be carried in the echo reply message but also in the
> time exceeded message?
> > Thanks, Frank
> > (BTW - Note that due to the upcoming holiday season, replies might be
> delayed).
> > > -----Original Message-----
> > > From: ippm <[e-mail]> On Behalf Of [e-mail]
> > > Sent: Friday, 10 December 2021 08:01
> > > To: [e-mail]
> > > Subject: [ippm] Progressing draft-ietf-ippm-ioam-conf-state
> > >
> > > Hi IPPM WG,
> > >
> > > The -02 version of draft-ietf-ippm-ioam-conf-state has been posted.
> > > There are mainly two changes, one is on IOAM Tracing Capabilities
> > > Objects to make them applicable to ICMPv6 extensions, another one is
> > > on IOAM Proof-of- Transit Capabilities Object to make it aligned
> > > with the updated IOAM-Data document.
> > > Also note that I've had an offline discussion with wg chairs and
> > > Frank Brockners, my conclusion is that Frank's concern raised at
> > > IETF 112 has been addressed. If that's not the case, please speak up.
> > > With that said, I think this draft is ready for WGLC.
> > >
> > > Best Regards,
> > > Xiao Min
> > >
> > > _______________________________________________
> > > ippm mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ippm