Subject: [Ippm-ioam-ix-dt] IOAM Flag Draft: Loopback on the Reverse Path

From: Tal Mizrahi <[email-masked]>
Date: Sun, 30 Aug 2020 09:03:22 +0300

Hi,

This is a short summary of the open issue we have about loopback on
the reverse path.
The loopback flag indicates to transit IOAM nodes that they need to
loop back the packet. When an IOAM packet is looped back we want it to
be forwarded back to the encapsulating node so that (1) no data fields
will be pushed along the reverse path, and (2) the encapsulating node
will know that this is a looped back packet and terminate it.

We have discussed five possible options of how to indicate that a
looped back packet is in transit on the reverse path:
- Flag: A dedicated flag (new flag) that indicates that a packet is looped back.
- IOAM type: A dedicated IOAM type that indicates this.
- RemainingLen: An IOAM transit node that loops back the packet clears
the RemainingLen field. This will not work for the pre-allocated trace
option.
- Exporting format: A packet on the reverse path is sent with an
exporting format (e.g., using the IOAM raw exporting format).
- E2E option: A packet that is intended for loopback includes an E2E
option that includes the ID of the encapsulating node, and an
indication about whether the packet is on the reverse path.

Thoughts/preferences?

Cheers,
Tal.

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 31 Aug 2020 15:04:49 +0000

Thanks Tal for the summary.

IMHO there is another important requirement that we should take into consideration: "Looped back packets MUST NOT leak from the IOAM domain".

Given that appropriate packet filtering at the edge of an IOAM domain is typically seen as not sufficient, i.e. the current approach: "The source address of the original packet is used as the destination address in the copied packet." might create challenges, especially in case of asymmetric routes where the encap node that set the loopback bit does not see the returning loopback traffic.

Using a flag/IOAM-Option-Type/remaining-len-hack all require a proper filtering function at the IOAM edge to ensure loopback traffic does not escape.
A safer approach could be to use a proper encapsulation for sending the loopback packet to a particular node, i.e. the turn-around node would encap the packet (and eventually truncate it - per the discussion in the current doc) and send it to a *defined* destination - which is similar to your "exporting format" option.  This destination could either be defined out of band - or we could consider carrying it as part of the IOAM-Option-Type (e.g. we could make Loopback a specific flavor of DEX and carry the destination IP address in a header field). The latter would make using "loopback" more like traceroute today - i.e. you don't need a lot of network wide config to use it, but control everything on the source/encap node.

Thoughts?

Thanks, Frank 

> -----Original Message-----
> From: Ippm-ioam-ix-dt <[email-masked]> On Behalf Of Tal
> Mizrahi
> Sent: Sonntag, 30. August 2020 08:03
> To: [email-masked]
> Subject: [Ippm-ioam-ix-dt] IOAM Flag Draft: Loopback on the Reverse Path
> 
> Hi,
> 
> This is a short summary of the open issue we have about loopback on the
> reverse path.
> The loopback flag indicates to transit IOAM nodes that they need to loop back
> the packet. When an IOAM packet is looped back we want it to be forwarded
> back to the encapsulating node so that (1) no data fields will be pushed along
> the reverse path, and (2) the encapsulating node will know that this is a looped
> back packet and terminate it.
> 
> We have discussed five possible options of how to indicate that a looped back
> packet is in transit on the reverse path:
> - RemainingLen: An IOAM transit node that loops back the packet clears the
> RemainingLen field. This will not work for the pre-allocated trace option.
> - Exporting format: A packet on the reverse path is sent with an exporting
> format (e.g., using the IOAM raw exporting format).
> - E2E option: A packet that is intended for loopback includes an E2E option that
> includes the ID of the encapsulating node, and an indication about whether the
> packet is on the reverse path.
> 
> Thoughts/preferences?
> 
> Cheers,
> Tal.
> 
> --
> Ippm-ioam-ix-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm-ioam-ix-dt

---

From: Haoyu Song <[email-masked]>
Date: Mon, 31 Aug 2020 16:42:16 +0000

Hi Tal,

The loopback works only if "the encapsulating node is available in the encapsulation header". Can you give some examples that the encapsulating nodes are identifiable?

As for the solutions, I support (option 1) Using a new flag or (option 4) exporting to the encapsulating node, because these options are simple and involve least extra efforts. 

Best regards,
Haoyu
-----Original Message-----
From: Ippm-ioam-ix-dt <[email-masked]> On Behalf Of Tal Mizrahi
Sent: Saturday, August 29, 2020 11:03 PM
To: [email-masked]
Subject: [Ippm-ioam-ix-dt] IOAM Flag Draft: Loopback on the Reverse Path

Hi,

This is a short summary of the open issue we have about loopback on the reverse path.
The loopback flag indicates to transit IOAM nodes that they need to loop back the packet. When an IOAM packet is looped back we want it to be forwarded back to the encapsulating node so that (1) no data fields will be pushed along the reverse path, and (2) the encapsulating node will know that this is a looped back packet and terminate it.

We have discussed five possible options of how to indicate that a looped back packet is in transit on the reverse path:
- Flag: A dedicated flag (new flag) that indicates that a packet is looped back.
- IOAM type: A dedicated IOAM type that indicates this.
- RemainingLen: An IOAM transit node that loops back the packet clears the RemainingLen field. This will not work for the pre-allocated trace option.
- Exporting format: A packet on the reverse path is sent with an exporting format (e.g., using the IOAM raw exporting format).
- E2E option: A packet that is intended for loopback includes an E2E option that includes the ID of the encapsulating node, and an indication about whether the packet is on the reverse path.

Thoughts/preferences?

Cheers,
Tal.

--
Ippm-ioam-ix-dt mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm-ioam-ix-dt&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C9844f05dbafd4e62d5c508d84caa93b6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637343642883446137&amp;sdata=BXOzLFV%2F5DY3ZBRDSqnMrCBFmg1tAR%2FSveVqA7H9460%3D&amp;reserved=0