renghardt
commented
4 years ago Replies from e-mails:
To [Med30]: "Noted" - so yes, let's see if we can come up with a good definition of domain, or if we want to get rid of the distinction. What do you think, Cyrill?
To [Med31]: "> [Med] even at L3, that host does not belong to same domain.
[TE] I guess whether a specific path element belongs to a specific domain depends on the exact definition of domain. If it's defined by "who owns the address space on L3", I don't see why it wouldn't belong to that domain."
Also: "[Med] May be, but my main concern (still) is whether there is a need to define domain/backbone."
So, I guess these comments are related to the exact definition of domain and on the question whether we keep this concept in our draft or get rid of the distinction.
To [Med32]: "[Med] I was concerned about "relationships between hosts and path elements within the same domain ". Contracts are usually between elements that do not belong to the same domain.
[TE] That's for a different definition of domain. But yes, contracts may exist with different entities along the path, so we'll rethink this along with the definition and notion of domain."
To [Med37]: "> [Med] I think the disconnect is the terminology but also the architectural assumptions. Usually, access technology is used between a device an access network with distinct administrative boundaries.
[TE] Yes, it's often the first link between a device and the node which is the first hop, such as an access point or base station. Does it help if we just remove "in the same domain" or change it to "in the local" network or something similar? Because I think we can define this regardless of the larger "domain" issue."
On "3. Domain properties": [Med28]: I’m afraid this section (and section 4) implies architectural considerations which may not be appropriate in a terminology document. As the scope of this document is to answer the first question of the Questions draft (Section 2.1 in draft-irtf-panrg-questions), "how are path properties defined and represented?", yes, this is a terminology document, but I wonder if possible classification of path properties is in scope. Here, our intention was to introduce such classification (e.g., dynamic and non-dynamic) to make it easier to reason about different properties, their usefulness, etc. However, I'm not sure if the classification into "domain" and "backbone" properties is indeed the right way to go. In the draft we give a number of reasons why it may matter if a path element is in the same administrative domain as a host or not. I'm sure there's a number of considerations here that may already touch upon other questions of the Questions draft, e.g., the second question of Discoverability, Distribution, and Trustworthiness of path property. However, the second question already asks how an endpoint can get access to trustworthy path properties, which we do not attempt to answer in this draft. So I'm not sure what the right trade-off here is between focusing the document on terminology and definitions vs. discussing considerations of where path elements may be located and who may control them. I'm very interested to get guidance from the Research Group here.
On "the first few hops": [Med29]: 2, 10 ? We kept this intentionally vague to cover both cases in we really consider only the first hop and cases in which we consider the entire access network behind that hop as well. I think deciding whether we want a clear definition here depends resolving the issue raised by the comment [Med28] above.
On "the same administrative domain as a host considering them." [Med30]: L2, L3, ? Personally I mostly think about domains in this document as everything covered by the same AS, but yes, it would be very interesting to come up with a clear definition of domain here. For example, PCE defines a domain as a "collection of network elements within a common sphere of address management or path computation responsibility, can be IGP areas, ASes, multiple ASes within a Service provider network. may also exist as sub-domains of areas or ASes.". PANRG is more broad, but maybe we can come up with something similar here? Again, I think deciding whether we want a clear definition here depends resolving the issue raised by the comment [Med28] above.
[Med31]: This would exclude then a host connected to a UE connected to a PLMN or a CPE connected to an enterprise or provider networks. These elements do not belong to the same administrative entity. In my understanding, an element belonging to an administrative domain does not necessarily mean that the element belongs to the entity which owns the domain. For example, if my phone (the UE) connects to a cellular network (the PLMN), the mobile phone still belongs to me. However, the phone might also be a host on a path through this cellular network. In this case, I intend the definition to have the phone, the base station, and the cellular infrastructure behind the base station all belong to the same administrative domain, as for example all L3 devices here get assigned IP addresses from a common address space that belongs to the provider of the cellular network. If my phone leaves the cellular network, it does not keep the IP address, then it's no longer part of that administrative domain. Can we come up with a more general definition of a domain that does not rely only on IP address space? Again, I think deciding whether we want a clear definition here depends resolving the issue raised by the comment [Med28] above.
On "Due to the potential physical proximity and pre-existing trust or contractual relationships between hosts and path elements within the same domain, domain properties may be more accessible to the host than other properties." [Med32]: Which contractual relationships would apply to this case? For example, if my host connects to a service provider's network, I may be a customer of this service provider, e.g., through my DSL subscription. This MIGHT mean that the provider is more willing to or has to give me (or my host) more information, e.g., about network performance characteristics. Physical proximity is easier, I think: A WiFi AP may send out information of its currently observed channel utilization within QBSS information elements. A host only gets this information because it's directly connected to the AP, which implies physical proximity. Again, such considerations already touch upon the second question of the Questions draft. [Med33], on the same text: I’m not sure about this. This may not always be the case, naturally. We just thought it might be helpful to state that it might be the case to motivate our classification into domain and backbone properties. Again, this depends on [Med28] resolution.
On "hosts may be able to influence […] which domain they are in" [Med34]: Connecting to a domain does not mean that the host belongs to that domain. Then this is a wording issue and we should change something in our definition to "connect to a domain" or "be in a domain" instead of "belong to a domain". However, again, this depends on [Med28] resolution.
On "they may be able to influence the properties of path elements within this domain." [Med35]: An example ? Given in the rest of the paragraph: "when connected to an Access Point, the user may move closer to enable their device to use a different access technology, potentially increasing the data rate available to the device." [Med36]: How a host can influence the one-way delay provided by a network? Probably not. We never suggest that a host can influence ALL properties.
On "Access Technology: The physical or link layer technology used for transmitting or receiving a flow on one or multiple path elements in the same domain. The Access Technology may be given in an abstract way, e.g., as a Wi-Fi, Wired Ethernet, or Cellular link. It may also be given as a specific technology, e.g., as a 2G, 3G, 4G, or 5G cellular link, or an 802.11a, b, g, n, or ac WiFi link. Other path elements relevant to the access technology may include on-path devices, such as elements of a cellular backbone network. Note that there is no common registry of possible values for this property." [Med37]: This is basically in a domain != from the local network Why not in the local network? I think this specifically applies to many local networks, where it's actually interesting if, e.g., a WiFi AP supports 802.11ac or not. Perhaps I'm misunderstanding something your comment, could you clarify, please?
On "[Monetary Cost: The price to be paid to transmit a specific flow across a] subpath." [Med38]: A network Right now, in the context of a path, all path elements within the network form a subpath. So this applies to the subpath. However, if we extend our terminology to include aggregated/abstract path elements, maybe we can have an abstract path element that represents a network.