Clarify Interface IDs & ConsIngress/ConsEgress & Router Alert flags

[nicorusti]

Current text is confusing

TODOs:

• [x] Clarify use of the ConsEgress Router Alert flag
• [ ] ConsIngress and ConsEgress are just instances of interfaces Identifiers, we should make this clearer (e.g. when we define interface IDs).
• [ ] ... (see feedback below)

Reviewer feedback

Harald Alvestrand Endpoint addresses consist of an AS number, an interface ID, and a “next protocol” address. This last is presumably only useful at SCION endpoints.

My answer: One of the fields in a SCION address is the ISD (Isolation Domain) number, not the interface ID. We mention "a complete SCION address is composed of the <ISD, AS, endpoint address>” in section 1.3.1. The we show the address header in 2.2.2. If this is too late in the draft, we could add some text earlier to clarify this. Interface IDs, instead, are part of hop fields (interface IDs are in the the ConsIngress / ConsEgress). Perhaps the confusing fact is that the field is called ConsIngress/Egress. This is because these fields refer to interface IDs in the direction the link was discovered during path construction (beaconing).

Harald Alvestrand There’s a weakly described feature (which still gets 16 bits in the header!) called “ConsIngress” and “ConsEgress”, which says that “routers will do L4 processing”, without calling out what that is - Traceroute is briefly mentioned, but not to a degree that would allow implementation of whatever-it-is-supposed-to-be.

Response: You are probably referring to the ConsEgress Router Alert flag, right? Thank you for spotting this, the description should be extended. This is actually one bit, we’ll add some explanation on this flag. (I see how the current description is somehow confusing). Besides that, ConsIngress and ConsEgress are just instances of interfaces Identifiers, we probably have to make this clearer. Regarding traceroute, this is an example of how this might be used (there is a SCON trace route application). As we don’t describe it, I’d remove it.

Eliot, 20.07.2024 ConsIngress and ConsEgress require a lot more explanation if they're to be included.

Arald Alvestrand, 20.07 There’s a weakly described feature (which still gets 16 bits in the header!) called “ConsIngress” and “ConsEgress”, which says that “routers will do L4 processing”, without calling out what that is - Traceroute is briefly mentioned, but not to a degree that would allow implementation of whatever-it-is-supposed-to-be.

Note: we use naming ConsIngress, ConsEgress because of https://github.com/scionproto/scion/issues/1479

[jiceatscion]

While researching traceroute, I wasn't able to figure out what it accomplishes: the path is already determined, link failures would be reported by scmp errors, and ping would be available to provide positive confirmation. So, what's left for traceroute to do? If traceroute is useless (not mentioning we don't really want to describe SCMP messages besides link failures), then so are the router alert flags and the associated behavior. Should we just mark them as reserved for future use and delete all mentions of traceroute (and deprecate that stuff from our code)?

From my naive perspective, it seems that router alert flags were a solution in search of a problem and that traceroute was invented as an example (contrived) of their use.

To be fair, the concept that a packet can contain a payload to be processed by the router itself seems potentially useful. Even if traceroute is a poor example. I can imagine remote administration protocols, for example. So, how about we simply state that these flags are there to enable messages destined to the router itself, but that such messages are a future extension. WDYT?

[nicorusti]

So, what's left for traceroute to do?

AFAIK, SCION traceroute is meant to allow the endpoint to be informed of ISD,ASes traversed, because the SCION path only contains a sequence of interface IDs (but not the ISD and AS numbers).

Should we just mark them as reserved for future use and delete all mentions of traceroute (and deprecate that stuff from our code)?

I think router alert flags are there in the deployed protocol, so we cannot remove them. We can leave them there and mention that they are reserved for options that must be processed at each router.

@oncilla did I get it right? Is there any other critical use of traceroute or router alert flags, that makes them necessary for the current deployment?

[oncilla]

Traceroute is an essential SCMP message to discover path health in the current implementation. Both the IP-SCION Gateway and scion showpaths rely on it. We cannot simply remove it without an appropriate replacements.

FWIW, I think the readers are a bit confused as they seem to think the router alert flag and the interface IDs are somehow the same thing.

[nicorusti]

FWIW, I think the readers are a bit confused as they seem to think the router alert flag and the interface IDs are somehow the same thing.

Yes, this is the main point.

Traceroute is an essential SCMP message to discover path health in the current implementation. Both the IP-SCION Gateway and scion showpaths rely on it. We cannot simply remove it without an appropriate replacements.

Thanks for the clarification @oncilla. We are trying to limit the scope of the drafts as much as possible, for now we tried avoiding having to describe in full SIGs and SCMP (which might be another two drafts on their own). So we are trying to strike the right balance to add what is necessary for the data plane draft to be clear and self sufficient.

[jiceatscion]

Ok, in this case, I propose to extend https://github.com/scionassociation/scion-dp_I-D/pull/49 in the following manner:

• Move SCMP to its own main section.
• Refer to the appropriate subsection of it in the link-failure notification section.

[jiceatscion]

Still a bit of clarification needed for the two flags.