Re: [ippm] Issue with draft-ietf-ippm-ioam-data

[Stewart Bryant <[e-mail]>]

Hi Frank,

> On 27 May 2021, at 20:28, Frank Brockners (fbrockne) <[e-mail]> wrote:
> 
> Hi Stewart,
>  
> From: Stewart Bryant <[e-mail] <mailto:[e-mail]>> 
> Sent: Donnerstag, 27. Mai 2021 17:45
> To: IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Cc: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Subject: Issue with draft-ietf-ippm-ioam-data
>  
> I have been looking at "Data Fields for In-situ OAM" draft-ietf-ippm-ioam-data-12 as part of some work that we are doing in MPLS.
>  
> The following came up in an MPLS design team meeting:
>  
> In para 5.4 IOAM Trace Option-Types
> 
> In the section on Incremental Trace-Option: there is the text:
>  
> The IOAM
>       encapsulating node allocates space for the Incremental Trace
>       Option-Type. 
>  
> One interpretation of this is that the ingress node preallocates space that the P nodes draw down on as needed to include their IOAM information.
>  
> …FB: There are two IOAM Trace-Option Types defined. In case of the “Pre-allocated Trace-Option”, the encapsulating node pre-allocates space in the IOAM header that transit nodes will fill in their IOAM information. In case of “Incremental Trace-Option”, the encapsulating node won’t pre-allocate space for transit nodes but the transit nodes will allocate space and fill in their information at the same time. See alsohttps://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-02#page-14 <https://datatracker.ietf.org/doc/html/draft-brockners-opsawg-ioam-deployment-02#page-14> (will be refreshed soon).

SB> None, the less the draft I reference does need to be clarified before it becomes an RFC, because there were a number of opinions of what the text meant.

>  
> Note that draft-ietf-ippm-ioam-data is focused on defining the data-fields for IOAM. BCP use of these data fields is discussed in the draft focused on IOAM deployment: draft-brockners-opsawg-ioam-deployment. The need for a more detailed discussion of the MTU aspects of IOAM came up in the recent IESG review – and those aspects will also be included in draft-brockners-opsawg-ioam-deployment moving forward.

SB> They clearly need discussing, but I am not sure the RFC we are talking about here should be published without either significant text on this important matter, or a normative reference to such a text. One reason to do this is to avoid late surprises with drafts that use the IOAM concept without studying its use in completely different data plane designs.

>  
> In addition: The encapsulation of IOAM into a specific protocol is typically handled in a dedicated draft (e.g., draft-ietf-sfc-ioam-nsh covers the encapsulation of IOAM into NSH). As such, I’d expect that the aspects of encapsulating IOAM into MPLS would be handled by a dedicated draft. Such a draft would detail how IOAM Option-Types are encapsulated and even whether all IOAM data fields and Option-Types would apply to that particular encapsulation.
>  
> Your message made me curious: I’m not aware of a draft that specifies IOAM encapsulation into MPLS – are you working on one?

SB> In MPLS we are looking at how we carry metadata, although I think it is more properly called auxiliary data as it provides essential assistance rather than clarifying description.

SB> One of the concepts that is on the table is to use pointers from the stack to auxiliary data to allow the specification of which AD element applies at a particular hop. This is particularly important in SR where you may you may not want to process all items at a particular hop or you may want to specify a parameter at a particular hop. Examples of the latter might be latency specification at a hop, partial IOAM, FRR advice etc. Fundamental to SR is moving the packet customisation from the control plane, or LSP construction to the packet itself.

SB> The advantage of using a pointer is that you go straight to the AD element you need without some deductive phase. The deductive phase is something that is always problematic in the use of implicit extension header selection, but if we can get to a explicit selection, there are many things that become much easier.

SB> The problem is of course not with variable length MD elements it is with *varying* length elements.

SB> Of course we are looking at a number of alternatives and pointers are just one approaches, but in discussions we came across this ambiguous wording.

SB> At a higher level, having a mid-node “randomly” insert data into a packet and expand its length is not something that we generally support in networking, and I am not sure we fully understand the consequences, or the limitations that it will impose on future development of the IP/MPLS network protocols. It is something that the wider community need to think very carefully about.

SB> I am of course sorry for raising this issue so late in the process, but this is the first time it has come to my attention,

Best regards

Stewart


>  
> Thanks, Frank
>  
>  
> Others thought that the the P nodes did an insertion into the packet by essentially moving all previous bytes to the “left” and adding in new information.
>  
> This clearly needs to be clarified in the text.
>  
> I also think the MTU text needs to be expanded because P routers now need to understand the MTU which was something that was not previously required.
>  
> Best regards
>  
> Stewart
>