Re: [ippm] Type-P-Reordered Dst param

Hi Spiros,
adding to Henk's reply, below:

At 09:19 AM 11/16/2005, Henk Uijterwaal wrote:
>At 15:13 16/11/2005, Spiros Spirou wrote:
>>Hi,
>>
>>In section 3.2 of draft-ietf-ippm-reordering-10 the Dst parameters of the
>>Type-P-Reordered is defined as "the IP address of a host". I assume that
>>this is not the destination IP field of the packet's IP header because
>>multicast and broadcast IPs don't qualify as "host IPs". So, is it correct
>>to report the unicast IP address of the interface that the packet was
>>received on (think about multihomed receivers)? Which IP should be reported
>>in case of multiple unicast IPs on the receiving interface?
>
>This comes from the framework and (AFAIK) multiple interfaces or interfaces
>with multiple addresses were not discussed when the framework was built.

The framework is Unicast-oriented (there are no instances of "multicast"
or "broadcast" in the text of RFC 2330), and Dst is consistently defined
as above in all current IPPM RFCs.  Unicast was the right place to
start, and IPPM's first foray into the world of one-to-many is the
multi-metrics draft: draft-stephan-ippm-multimetrics-01.txt

In the Reordering draft, section 2.3
"Required Context for All Reordering Metrics" gives the opportunity
to report any and all relevant information under the
"Packet of Type-P" category (including transport addresses).

Al

>However, Src and Dst are there to identify the host that sent or received
>the packet(s) in the test.  If a host has multiple interfaces or multiple
>addresses on an interface, I'd report the address that was actually used.
>This uniquely defines the host and also allows one to select traffic
>based on the path it took.   Packets sent from/to eth0 may be treated
>differently than to eth1, packets sent from/to 192.168.0.0/24 may be
>treated differently than packets sent from/to 192.168.1.0/24.
>
>Henk

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm