Add "routing domain identifier"

[SpencerDawkins]

In PANRG discussion about draft-irtf-panrg-questions, we tripped over that draft using the term "control plane address", with no definition, either in draft-irtf-panrg-questions or in the path-properties draft.

Based on discussion on the PANRG mailing list, we seem to be changing that to "routing domain identifier" (discussion thread is at https://mailarchive.ietf.org/arch/msg/panrg/BzPUTAZo0apm1HQ-wTE7xIq6g30/).

Should this term be added to "path properties", since it's being used in our research group documents?

(This is probably also a good question for @britram and @furry13}

[renghardt]

Following the discussion at the IETF 112 PANRG session, it sounds to me like we should add this definition if it doesn't have an obvious, widely understood meaning.

It seems like "routing domain" does have a definition in RFC1237, it is "a collection of networked systems that operate common routing protocols and are under the control of a single administration". Then, RFC 1629 defines the OSI Interdomain Routing Protocol (IDRP), which has the concept of a Routing Domain Identifier (RDI), and RFC1930 says "It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier.". These definitions seem kind of historic, and I haven't found any more current RFCs.

But I did find:

• a random website claiming a "routing domain" is an AS, so a routing domain identifier would be an ASN.
• F5 defining a route domain as a configuration object that isolates network traffic for a particular application on the network. I'm not sure if this is the same as a routing domain, but the latter term does appear on that page, too, and it looks like it's used as a synonym.
• A patent application by Nicira, which talks about ways to assign a routing domain identifier to one or more logical switches, but I'm not seeing a proper definition in there.

Perhaps, in the path properties draft, we could link to RFC1237 and then maybe qualify that, in the context of PANRG, a routing domain can be any collection of nodes and links which can communicate with each other, operate a common routing protocol, and are under the control of a single administration?

Note that we do already define an "Administrative Domain", and maybe the "routing domain" could fit in there and/or we could change this definition to talk about routing domains instead.

Thoughts?

[cyrill-k]

I think using RFC 1237 as a reference is a good idea because our definition of administrative domain is a superset of their definition (if I understand the terms used in the RFC correctly).

We could maybe have the property routing domain after the property administrative domain, and then explicitly use your proposed (slightly modified) definition:

a routing domain is an administrative domain consisting of a collection of nodes and links which can communicate with each other and operate a common routing protocol.

And then we also introduce the term routing domain identifier in the same paragraph.

An alternative way could be to simply merge these two property definitions, which would slightly restrict the scope of "administrative domains" to only cover "routing domains". The only issue would then be an administrative domain that covers multiple networks with different routing protocols. However, I'm not sure how likely such a scenario is in practice.

[SpencerDawkins]

The only issue would then be an administrative domain that covers multiple networks with different routing protocols. However, I'm not sure how likely such a scenario is in practice.

Do you mean different routing protocols, or different routing domains? I'm confused here.

[cyrill-k]

I meant a single administrative domain that covers multiple routing domains, which potentially run different routing protocols.

[renghardt]

Generally, I'm in favor of having fewer examples. The beginning of Section 4 says that this document covers:

[…] examples of path properties which may be useful, e.g., for the use cases described in Section 3 [Path Selection, Protocol Selection, Service Invocation].

So, do we need "administrative domain" as its own separate example of a path property? I think its usefulness is mostly implied in Section 5, Security Considerations, as the trust relationship that entities need to build changes if entities are in the same administrative domain or not.

I think that's enough to keep the example, as the usefulness of the administrative domain really has nothing to do with the routing protocol being used - At least I think that the routing protocol used would not change your approach to trusting a path property.

The more I think of it, the more I am against merging the "administrative domain" and the "routing domain" definitions, and in favor of keeping the administrative domain and adding a routing domain example property.

If we do keep the administrative domain example, we should change its definition, as we currently define it by itself. I remember discussing this path property example a while ago, and I don't think we could quite grasp a proper definition. Today I would say it's an individual or organization that owns a path element (or sequence of path elements).

Then, perhaps a routing domain identifier could be a common identifier for a set of path elements which are owned by the same individual or organization, can communicate with each other, and where the nodes use a common routing protocol. (We do define a path property as relative to a sequence of path elements, not a set... But I suppose there's no rule saying that the same path property value can't apply to multiple path elements or paths.)

Would you like to take a stab at a PR, @cyrill-k? Otherwise I'm happy to do it.