Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 11 Apr 2013 20:17:09 +0000

> Question 2: IPv4/IPv6
> Do we agree that we need support both IPv6 and IPv4?
> Note: The issue of NAT traversal complicates IPv4

As for the measurements/tests: We should expect the lmap architecture to allow for tests that run across both/either IP protocol version. I'm definitely aware of there being interest in tests run over both protocols if the end user's network is enabled for both. Especially tests around latency. I consider lmap as mostly being about control/management/configuration of tests, MAs, and the physical devices/elements containing these. I do not envision lmap being about trying to control intermediate transport elements to enable tests to run through them. If a test intended to be run over IPv4 can't traverse a NAT, then that test has no business being run, IMO. But there are lots of tests that can and do traverse NAT without problem.

As for the protocols that might be used by various management/control/data collection protocols: Unless there is to be a brand new protocol, any existing protocol should already have definitions for how to run it over IPv4 or IPv6. If it doesn't, I don't envision lmap trying to solve that problem. I'm hoping there won't be any brand new management protocols.
Barbara

---

From: Brian Trammell <[email-masked]>
Date: Fri, 12 Apr 2013 09:46:36 +1200

Hi, Barbara, all,

+1. Indeed, as various messy NAT-for-transition setups see wider deployment, some tests may involve the testing of connectivity and application-layer response time to various points in the v4 and v6 Internet from both v4 and v6 local addresses. The parameters for these tests will therefore be (1) necessarily complicated by the NAT they're trying to measure and (2) necessarily involve the specification of both address families.

Best regards,

Brian

On 12 Apr 2013, at 8:17, "STARK, BARBARA H" <[email-masked]> wrote:

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Thu, 11 Apr 2013 20:01:28 -0400

Some of the complexity brought to a network near you by NAT
has been embraced in the reference path draft, and this is 
one of the areas we expanded in the 01 version:
http://tools.ietf.org/html/draft-morton-ippm-lmap-path-01

Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Trammell
> Sent: Thursday, April 11, 2013 5:47 PM
> To: STARK, BARBARA H
> Cc: Benoit Claise; [email-masked]
> Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6
> 
> Hi, Barbara, all,
> 
> +1. Indeed, as various messy NAT-for-transition setups see wider
> deployment, some tests may involve the testing of connectivity and
> application-layer response time to various points in the v4 and v6
> Internet from both v4 and v6 local addresses. The parameters for these
> tests will therefore be (1) necessarily complicated by the NAT they're
> trying to measure and (2) necessarily involve the specification of both
> address families.
> 
> Best regards,
> 
> Brian
> 
> > As for the measurements/tests: We should expect the lmap architecture to
> allow for tests that run across both/either IP protocol version. I'm
> definitely aware of there being interest in tests run over both protocols
> if the end user's network is enabled for both. Especially tests around
> latency. I consider lmap as mostly being about
> control/management/configuration of tests, MAs, and the physical
> devices/elements containing these. I do not envision lmap being about
> trying to control intermediate transport elements to enable tests to run
> through them. If a test intended to be run over IPv4 can't traverse a NAT,
> then that test has no business being run, IMO. But there are lots of tests
> that can and do traverse NAT without problem.
> >
> > As for the protocols that might be used by various
> management/control/data collection protocols: Unless there is to be a
> brand new protocol, any existing protocol should already have definitions
> for how to run it over IPv4 or IPv6. If it doesn't, I don't envision lmap
> trying to solve that problem. I'm hoping there won't be any brand new
> management protocols.
> > Barbara

---

From: <[email-masked]>
Date: Fri, 12 Apr 2013 14:14:39 +0100

agree with the comments

as regards teh control protocol, the measurement agent may be behind a NAT (or even two? for MA on CPE inside the home network). 
so the control protocol needs to cope with this - which might partly involve an initialisation function ('Management Server' in the Broadband forum's liaison) that tells the MA where a collector is. in my mind it's an open question whetehr lmap defines an initialisation function or leaves this to BBF.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of MORTON JR., ALFRED C (AL) [[email-masked]]
Sent: 12 April 2013 01:01
To: Brian Trammell; STARK, BARBARA H
Cc: Benoit Claise; [email-masked]
Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6

Al

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Apr 2013 16:59:22 +0200

On Fri, Apr 12, 2013 at 02:14:39PM +0100, [email-masked] wrote:

> as regards teh control protocol, the measurement agent may be behind
> a NAT (or even two? for MA on CPE inside the home network).  so the
> control protocol needs to cope with this - which might partly
> involve an initialisation function ('Management Server' in the
> Broadband forum's liaison) that tells the MA where a collector
> is. in my mind it's an open question whetehr lmap defines an
> initialisation function or leaves this to BBF.

I assume there will likely be different bootstrapping mechanisms since
networks and scenarios differ a lot. It is important that lmap clearly
defines what information a bootstrapping mechanism needs to provide.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 19 Apr 2013 16:52:41 +0200

Dear all,

So it seems clear from the answer that we want both IPv4 and IPv6 supports.

Regards, Benoit