Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Roman,

> -----Original Message-----
> From: Roman Danyliw <[e-mail]>
> Sent: Mittwoch, 11. August 2021 22:40
> To: Frank Brockners (fbrockne) <fbrockne=[e-mail]>; The
> IESG <[e-mail]>
> Cc: Al Morton <[e-mail]>; [e-mail]; draft-ietf-ippm-
> [e-mail]; [e-mail]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12: (with
> DISCUSS and COMMENT)
> 
> Hi Frank!
> 
> > -----Original Message-----
> > From: iesg <[e-mail]> On Behalf Of Frank Brockners
> > (fbrockne)
> > Sent: Monday, April 26, 2021 11:38 AM
> > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > Cc: Al Morton <[e-mail]>; [e-mail];
> > draft-ietf-ippm- [e-mail]; [e-mail]
> > Subject: RE: Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12:
> > (with DISCUSS and COMMENT)
> >
> > Hi Roman,
> >
> > Thanks a lot for your review - and sorry for the delay in responding.
> > Please see inline ("..FB").
> >
> > > -----Original Message-----
> > > From: Roman Danyliw via Datatracker <[e-mail]>
> > > Sent: Mittwoch, 24. März 2021 16:06
> > > To: The IESG <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; Al Morton <[e-mail]>;
> > > [e-mail]
> > > Subject: Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12:
> > > (with DISCUSS and COMMENT)
> > >
> > > Roman Danyliw has entered the following ballot position for
> > > draft-ietf-ippm-ioam-data-12: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Please clarify what constitutes the edge or boundary of the IOAM domain.
> > > Consider:
> > >
> > > (a) Section 4.
> > > IOAM is a
> > >    network domain focused feature, with "network domain" being a set of
> > >    network devices or entities within a single administration.
> > > …
> > > Designers of
> > >    protocol encapsulations for IOAM specify mechanisms to ensure that
> > >    IOAM data stays within an IOAM domain.  In addition, the operator of
> > >    such a domain is expected to put provisions in place to ensure that
> > >    IOAM data does not leak beyond the edge of an IOAM domain.
> > >
> > > (b) Section 5.3.
> > > Namespace identifiers allow devices which are IOAM capable to
> > >    determine: …
> > > whether IOAM-Option-Type(s) has to be removed from the packet,
> > >       e.g. at a domain edge or domain boundary.
> > >
> > > (a) suggests that the filtering occurs on the basis of the single
> > > administrative domain.  However, (b) suggests that namespace
> > > identifiers are part of the filtering decision; which suggests that
> > > sub-domains can be created in a given domain which should be
> > > partitioned
> > from each other.
> > >
> > > The Security Considerations should be clearer on who does the IOAM
> > > information filtering, on what criteria and on what boundary.
> >
> >
> > ...FB: Eric already suggested in his review that we refer to RFC 8799
> > and an IOAM domain classifies as a "Limited Domain" per RFC 8799,
> > which we plan to do for the next revision.
> > And per your comment, namespaces can indeed be used for further
> > segmentation of the single administrative domain.
> >
> > Given that draft-ietf-ippm-ioam-data is focused on the definition of
> > data-fields, we created a "sister" document, which is to discuss all
> > deployment related aspects of IOAM:
> > draft-brockners-opsawg-ioam-deployment (we're working on an updated
> > version as we speak). Domains and nodes are discussed in section 3,
> > see
> > https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment-
> > 02#section-3. With regards to filtering at the edge of the
> > administrative domain, draft-brockners-opsawg-ioam-deployment states
> > the following
> >
> >    The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating
> >    node is always performed within a specific IOAM-Namespace.  This
> >    means that an IOAM node which is e.g. an IOAM-decapsulating node for
> >    IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove
> >    the IOAM-Option-Types for IOAM-Namespace "A" from the packet.  An
> >    IOAM decapsulating node situated at the edge of an IOAM domain
> >    removes all IOAM-Option-Types and associated encapsulation headers
> >    for all IOAM-Namespaces from the packet.
> >
> > Does this clarify things? And if so, are you ok to keep "data fields definition"
> > and "deployment aspects" separated in the two different documents?
> > Otherwise, we would need to create redundancies between the documents,
> > which are a bit hard to keep in synch.
> 
> Thanks for -14.  If I understand things correctly, the text I was concerned about
> in Section 5.3, "o  whether IOAM-Option-Type(s) have to be removed from the
> packet, e.g. at a domain edge or domain boundary" is roughly saying that any
> Option-Type needs to be combined with the Namespace to completely
> understand it's semantics and how it should be actioned.  One of this actions (to
> the substance of the quoted text) could be to de-encapsulation because that
> particular Option-Type has reached its particular boundary.  The key principle
> that I wasn't following (correct me if I have it wrong) is that each namespace
> constitutes a different "IOAM Domain" and that a single "network domain"
> (under the control of a single administrative entity) may have multiple,
> overlapping "IOAM Domains".

..FB: Yes - this is indeed what the documents try to express. That is also the reason why there isn't a "domain identifier" or similar as part of the IOAM data fields, given that the association to domains can be achieved using namespaces. 

> 
> If the above is correct, then I think language in Section 3 of draft-brockners-
> opsawg-ioam-deployment is clear as is your explanation above.  Could you
> please add a bit of that clarification to the document.  I see the text about
> limited domain per Eric and concur with the sentiment of not repeating text
> already in the ops document.  With the use of four types of domains across the
> two documents (deployment, network, limited, and IOAM), I would offer this
> refinement to clear up this architecture principle (and leaves the rest of the text
> unchanged):
> 
> Section 4.
> 
> OLD
> A limited domain which uses IOAM is called an "IOAM domain".  An IOAM
>    domain is bounded by its perimeter or edge.
> 
> NEW (feel free to polish)
> A limited domain which uses IOAM may operate one or more "IOAM domain",
> each disambiguated through separate namespace identifiers.  An IOAM domain
> is bounded by its perimeter or edge.  IOAM domains may overlap inside the
> limited domain.

...FB: Thanks for the proposed text which helps clarify things. 
The only minor change I'd suggest is to switch "operate" to "constitute" and "more" to "multiple":

A limited domain which uses IOAM may constitute one or multiple "IOAM domains",
each disambiguated through separate namespace identifiers.  An IOAM domain
is bounded by its perimeter or edge.  IOAM domains may overlap inside the
limited domain.

OK? If so, we'll get this added to version -15 along with Murray's suggested edits.

Thanks, Frank

> 
> Regards,
> Roman