Subject: [Int-area] question about xping (draft-bonica-intarea-eping)

From: Sowmini Varadhan <[email-masked]>
Date: Tue, 28 Mar 2017 17:32:05 -0400

Hi,

The draft says 
   ".. the destination and probed
   interfaces must be local to one another (i.e., both interfaces must
   belong to the same node)."

However, virtualization raises some questions about how this should work,
and maybe the draft should nail down some of the details with more 
clarity.

What if the probed interface is assigned to a different VRF than the
destination interface? e.g, What is the expected xping response
if I receive 
     # xping-I red0/0/0.0 10.10.10.1
on interface blue0 in the "blue" vrf, and red0 is in "red" VRF?
Does the answer change if the destination interface is on the
management VRF?

similar question for other forms of virtualization, e.g,,
What if the probed interface is assigned to a different 
network-namespace than the destination interface of an xping req?
Does it matter if the above xping is received on the default 
network namespace vs some other network namespace? 

One could argue that all the physical intefaces are owned by the "node"
(the management VRF? default netns?) but virtual interfaces like
tunnels and macvlans are a grayer area (unlike physical interfaces,
the latter do not default back to the mgmt VRF or default netns when
the virtual object is destroyed, so their ownership is unclear).

How should xping work in the face of virtual interfaces, e.g.,
the linux macvlan? How does it work when an interface is renamed?
Will xping allow me to probe for "tun0" or "Portchannel1"?

--Sowmini

---

From: Ron Bonica <[email-masked]>
Date: Tue, 28 Mar 2017 22:27:00 +0000

Hello Sowmini,

Good point! We addressed this in a previous version of the draft, but accidentally dropped it from the current version.

Our current thinking is:

- If the destination and probed interfaces are in the same VRF, the ICMP Extended Echo Reply message will reflect the state of the probed interface
- If the destination interface is in the general or management VRF and the probed interface is in another VRF, the ICMP Extended Echo Reply message will reflect the state of the probed interface
- Otherwise, the ICMP Extended Echo message will contain an error code indicating that the probed interface does not exist.

I will add this back to the next revision of the draft.

                                              Ron

> -----Original Message-----
> From: Sowmini Varadhan [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2017 5:32 PM
> To: Ron Bonica <[email-masked]>; Reji Thomas
> <[email-masked]>; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: question about xping (draft-bonica-intarea-eping)
> 
> Hi,
> 
> The draft says
> and maybe the draft should nail down some of the details with more clarity.
> 
> destination interface? e.g, What is the expected xping response if I receive
> Does the answer change if the destination interface is on the management
> VRF?
> 
> similar question for other forms of virtualization, e.g,, What if the probed
> interface is assigned to a different network-namespace than the destination
> interface of an xping req?
> Does it matter if the above xping is received on the default network
> namespace vs some other network namespace?
> 
> (the management VRF? default netns?) but virtual interfaces like tunnels and
> macvlans are a grayer area (unlike physical interfaces, the latter do not
> default back to the mgmt VRF or default netns when the virtual object is
> destroyed, so their ownership is unclear).
> 
> How should xping work in the face of virtual interfaces, e.g., the linux
> macvlan? How does it work when an interface is renamed?

---

From: Sowmini Varadhan <[email-masked]>
Date: Tue, 28 Mar 2017 18:41:44 -0400

On (03/28/17 22:27), Ron Bonica wrote:
> Good point! We addressed this in a previous version of the draft,
> but accidentally dropped it from the current version.
> 
> Our current thinking is:
> 
> - If the destination and probed interfaces are in the same VRF, the ICMP
> Extended Echo Reply message will reflect the state of the probed interface
> - If the destination interface is in the general or management VRF
> and the probed interface is in another VRF, the ICMP Extended Echo Reply
> message will reflect the state of the probed interface
> - Otherwise, the ICMP Extended Echo message will contain an error code
> indicating that the probed interface does not exist.
> 

Ok, but what about other forms of VRF-like virtualization like
network namespaces? Things can get a bit trickier here because the same
ifname can exist in multiple virtual objects.

Also, interface ownership can be more blurry for some of these
virtualization models like network namespaces- it's not always
clear that the hypervisor ("default netns") owns the interface,
when the interface is virtual. 

--Sowmini

---

From: Ron Bonica <[email-masked]>
Date: Wed, 29 Mar 2017 14:50:27 +0000

Sowmini,

You have convinced me that there should be no information leaking at all. So, I think that the next version of the draft should enforce the following rules:

-  If the destination and probed interfaces are in the same VRF/routing instance/namespace, the ICMP Extended Echo Reply message will reflect the state of the probe interface
- Otherwise, the ICMP Extended Echo message will contain an error code indicating that the probed interface does not exist.

Do you agree?

                                    Ron

> Sent: Tuesday, March 28, 2017 6:42 PM
> To: Ron Bonica <[email-masked]>
> Cc: Reji Thomas <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: question about xping (draft-bonica-intarea-eping)
> 
> > Good point! We addressed this in a previous version of the draft, but
> > accidentally dropped it from the current version.
> >
> > Our current thinking is:
> >
> > - If the destination and probed interfaces are in the same VRF, the
> > ICMP Extended Echo Reply message will reflect the state of the probed
> > interface
> > - If the destination interface is in the general or management VRF and
> > the probed interface is in another VRF, the ICMP Extended Echo Reply
> Ok, but what about other forms of VRF-like virtualization like network
> namespaces? Things can get a bit trickier here because the same ifname can
> exist in multiple virtual objects.
> 
> Also, interface ownership can be more blurry for some of these virtualization
> models like network namespaces- it's not always clear that the hypervisor
> ("default netns") owns the interface, when the interface is virtual.
> 
> --Sowmini

---

From: Sowmini Varadhan <[email-masked]>
Date: Wed, 29 Mar 2017 11:32:47 -0400

On (03/29/17 14:50), Ron Bonica wrote:
> 
> Sowmini,
> 
> You have convinced me that there should be no information leaking at
> all. So, I think that the next version of the draft should enforce the
> following rules:
> 
> -  If the destination and probed interfaces are in the same VRF/routing
> instance/namespace, the ICMP Extended Echo Reply message will reflect
> the state of the probe interface

Yes, that's a much more consistent model (esp since the same IP 
address can itself exist in multiple VRFs) and also extends without loss
of generality to other virtualization models.

thanks for addressing this!

--Sowmini