Subject: Re: [lmap] framework comments

From: <[email-masked]>
Date: Fri, 2 May 2014 08:40:46 +0100

Since this is an informational framework, I think this document is probably the wrong place to define such a default time.

phil

> -----Original Message-----
> From: Charles Cook [mailto:[email-masked]]
> Sent: 29 April 2014 16:55
> To: Eardley,PL,Philip,TUB8 R
> Cc: [email-masked]; [email-masked]
> Subject: Re: [lmap] framework comments
> 
> Phil,
> 
> Regarding prevention of the MA from continuously executing Measurement
> Tasks when contact with the Controller has been lost, I believe there
> needs to be a default time.  See inline below.
> 
> Charles
> 
> On 4/29/2014 4:31 AM, [email-masked] wrote:
> > Thanks!
> >
> >>> [phil] I agree with you, the MA does not have to be in the
> >>> customer's premises.
> >>> S6 - if anyone can contribute text of MAs located elsewhere, that
> >>> would be very helpful.
> >> <bhs> Yes, I'll propose some additional text. I'll do that in a
> >> separate email later this week.
> > Al wrote this text, what do you reckon?
> >
> > 6.2.5.  Measurement Agent embedded in ISP Networks
> >
> >    A MA may be embedded on a device that is part of an ISP's network,
> >    such as a router or switch.  Usually the network devices with an
> >    embedded MA will be stategically located, such as a Carrier Grade
> NAT
> >    or ISP Gateway.  [I-D.ietf-ippm-lmap-path] gives many examples
> where
> >    a MA might be located within a network to provide an intermediate
> >    measurement point on the end-to-end path.  Other examples include
> a
> >    network device whose primary role is to host MA functions and the
> >    necessary measurement protocol.
> >
> >>>> To avoid the MA generating
> >>>>    traffic forever after a Controller has permanently failed , it
> >> is
> >>>>    suggested that the Measurement Schedule includes a time
> limit...
> >>>> Comment: I thought we were also going to allow for the MA to just
> >>>> stop doing measurements if it didn't hear from the Controller in a
> >> while.
> >>> [phil] seems to me that these are equivalent, though I don't mind
> >> adding it.
> >> <bhs> Given the extensive discussion that was had about this, I'm
> >> curious as to what others think.
> > [phil] ok. I have changed to say:
> > To avoid the MA generating
> >    traffic forever after a Controller has permanently failed, the MA
> can
> >    be configured with a time limit; if the MA doesn't hear from the
> >    Controller for this length of time, thenl it stops operating
> >    Measurement Tasks.
> <cc> I don't think this solves the problem unless there is a default
> time limit that is used if a time interval is not specifically
> configured.
> 
> Perhaps something like,
> 
> "To avoid the MA generating traffic forever after a Controller has
> permanently failed, the MA will stop operating Measurement Tasks if the
> MA does not hear from the Controller for a default <tbd> length of
> time.  Optionally, the MA can be configured with a specific time limit;
> if the MA doesn't hear from the Controller for this length of time,
> then it stops operating Measurement Tasks."
> 
> 
> >
> >>> ...
> >>>
> >>>> 5.5.  Operation of LMAP over the underlying transport protocol
> And
> >>>> subsequent uses of "underlying transport protocol" in this
> section.
> >>>> Comment: The description of "transport protocol" in this section
> is
> >>>> unlike any use of "transport protocol" I've ever seen. Especially
> >>>> the part about there being Push, Pull, and multicast transport
> >> protocols.
> >>>> Multicast only happens at IP or Ethernet, to the best of my
> >> knowledge.
> >>>> I've never heard of a higher layer protocol capable of multicast.
> I
> >>>> usually associate "transport protocol" with protocols that operate
> >>>> at the transport layer, like TCP and UDP, or with protocols like
> >> RTP
> >>>> (that has Transport Protocol in its name). But RTP, TCP, UDP and
> >>>> such have no Push, Pull, or multicast characteristics. I'm not
> sure
> >>>> what to recommend about this section -- parts seem usable, but the
> >>>> way it's described doesn't relate to my understanding of the
> nature
> >>>> of various protocols.
> >>> Very open to suggested phrasings.
> >>> Key word is "underlying".
> >>> Simply mean that (say) the LMAP Control Protocol is Controller to
> >>> MA, but for instance if it operates over http, then at this
> "underlying"
> >>> layer the MA does a request (pull) to the Controller and its reply
> >>> includes the LMAP Control Protocol info. Or the "underlying" layer
> >> may be push or even multicast.
> >>> "transport" didn't mean layer 4 but something transporting the LMAP
> >> info.
> >>> Would "underlying packet transfer mechanism" or "model" be clearer?
> >> <bhs> So what I read you saying is that there are some
> >> characteristics that the Control or Report Protocol can "inherit"
> >> from underlying protocols (effectively defined as any protocol at
> any
> >> layer that is below the Control or Report Protocol). This much I
> >> agree with, and I think it would be good to rephrase along this
> line.
> >> However, http does not necessarily imply "Pull". Just because 2
> >> endpoints are in a client/server relationship for a Control or
> Report
> >> Protocol, doesn't mean that they maintain that same client/server
> >> relationship as it relates to http. That is, it's possible for the
> >> Controller to be the http client that initiates a http session to
> the
> >> MA (which is the http server). It can be the higher layer Control or
> >> Report protocol that dictates which endpoint can or must be the http
> >> client/server. For example, TR-069 does allow the TR-069 config
> >> server to initiate http with the TR-069 client for the purpose of
> >> sending a "connect to your config server ASAP" message. But only the
> >> TR-069 client can initiate a http session for purpose of receiving
> >> configuration info (in which case the TR-069 client is the http
> >> client and the TR-069 config server is the http server). And so I
> >> consider TR-
> >> 069 to be a "Pull" protocol. But it doesn't inherit this from http.
> >> Because either side can initiate http to the other at different
> times.
> >> It is TR-069 itself that defines the RPCs (remote procedure calls)
> >> and when different RPCs can be used.
> >> So I still have a problem with the idea that Push and Pull are
> >> necessarily inherited from underlying protocols, or that http
> implies
> >> "Pull".
> >> I agree that multicast is inherited.
> >>
> > In terms of how to change the text, the first 2 paras seem ok, but
> replace the last sentence with:
> > How this is done depends on the design of the Control and Report
> Protocols, the underlying packet transfer mechanism and how it is
> configured (for example, which endpoint is the HTTP client and which
> the server).
> >
> > And then change to:
> > For the Control Protocol, the underlying packet transfer mechanism
> could be used in a:
> >
> >    o  a 'push' mode (that is, from the Controller to the MA)
> >
> > and similar change for the other bullets.
> >
> > Does this work?
> >
> >>
> .......................................................................
> >>>> .....
> >>>> 5.6.1.  End-user-controlled measurement system ...
> >>>>        Note that a user can't directly initiate a Measurement
> >>>>        Task on an ISP- (or regulator-) controlled MA.
> >>>> Comment: Why not? Why isn't it allowed to include this ability in
> a
> >>>> MA design (such as one that is just for the ISP use case and has
> >>>> nothing to do with regulatory use case)?
> >>> [phil] then there would be two ways of controlling the MA, which is
> >>> something we want to avoid.
> >> <bhs> Multiple methods of remote configuration are indeed
> >> complicated, which was why I very much agreed with the "one
> Controller" restriction.
> >> But we have a lot of experience in coordinating between
> >> person-directed local configuration and remote automated
> >> configuration on various devices. Which is why I don't see it
> necessary to forbid this.
> > Would be interested to read more about this, do you have a ref
> please.
> >
> >>>> 6.2.3.  Measurement Agent embedded behind site NAT /Firewall
> >>>>
> >>>>    The Measurement Agent could also be embedded behind a NAT, a
> >>>>    firewall, or both.  In this case the Controller may not be able
> >> to
> >>>>    unilaterally contact the Measurement Agent unless either static
> >> port
> >>>>    forwarding configuration or firewall pin holing is configured.
> >> For
> >>>>    the former, protocols such as PCP [RFC6887], TR-069 [TR-069]or
> >> UPnP
> >>>>    [UPnP]could be used.  For the latter, the Measurement Agent
> >> could
> >>>>    send keepalives towards the Controller to prop open the
> firewall
> >>>> (and
> >>>>    perhaps use these also as a network reachability test).
> >>>> Comment: Regarding the last sentence, I don't understand what
> >>>> keepalives has to do with UPnP. Why not just mention STUN as an
> >>>> option for keeping NAT table entries from timing out?
> >>> [phil] "for the former" refers to "static port forwarding
> >>> configuration" and "for the latter" to "firewall pin holing"
> >> <bhs> Hmm. I think we have terminology-understanding differences at
> >> multiple levels here. In my use of the words, a port forwarding rule
> >> or mapping is a pinhole. They can be statically (manually, TR-069,
> >> SNMP) or dynamically (UPnP IGD, PCP) configured, or dynamically
> >> generated as a result of outbound TCP and UDP packets.  Because
> >> pinholes configured through PCP and UPnP IGD do expire after a
> while,
> >> and are created on an "as needed" basis, they tend to be considered
> dynamic and not static.
> >> Pinholes dynamically generated by the NAT or firewall processes as a
> >> result of outbound TCP or UDP packets don't tend to be considered
> >> "configured". I would suggest rewording this to:
> >>   The Measurement Agent could also be embedded behind a NAT, a
> >>   stateful-packet inspection firewall, or both.  In this case the
> >> Controller may not be able to  unilaterally contact the Measurement
> >> Agent unless configured or dynamically-generated pinholes exist.
> >>  Protocols such as PCP [RFC6887], CWMP [TR-069] or UPnP IGD  [UPnP
> >> IGD] can be used to configure pinholes.  For pinholes that are
> >> dynamically- generated as a result of outbound TCP or UDP packets,
> >>   the Measurement Agent could
> >>  send keepalives, such as those of the STUN protocol [STUN], towards
> >> the Controller to keep open the pinholes (and perhaps use these also
> >> as a network reachability test).
> >>
> >> I recommend referencing UPnP IGD, and not just UPnP. And calling the
> >> protocol described in TR-069 "CWMP".
> > Wfm. Thanks for the text.
> >
> >>>> --------------------------------
> >>>> 8.3.  Key Distinction Between Active and Passive Measurement Tasks
> >>>>
> >>>>    Passive and Active Measurement Tasks raise different privacy
> >> issues.
> >>>>    Passive Measurement Tasks are conducted on a user's traffic
> ,...
> >>>> Comment: This is not necessarily true if it is possible for the MA
> >>>> not to be located in a place where it is associated with a single
> >> end user
> >>>> or subscriber. I recommend "   Passive Measurement Tasks can be
> >>>> conducted on a user's traffic ,..."
> >>> [phil] how about " Passive Measurement Tasks are conducted on user
> >>> traffic"?
> >>> (I think "can be conducted" misleadingly hints "but may not be")
> >> <bhs> As has been discussed on this list, Passive Measurements can
> >> also be conducted on Active Measurement traffic. I don't consider
> MA-
> >> or MP- generated Active Measurement traffic to be user traffic. For
> >> MAs located outside the customer premises, it is also possible for
> an
> >> ISP to measure management traffic (between its network elements and
> >> systems).
> > Good point.
> >
> > Thanks
> > Phil.
> >
> > _______________________________________________
> > lmap mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/lmap
> 
> --
> 
> Charles Cook
> Principal Architect
> Network
> 5325 Zuni Street; Suite 224
> Denver, CO  80221
> Tel:  303.992.8952  Fax:  925.281.0662
> [email-masked]

---

From: Charles Cook <[email-masked]>
Date: Fri, 02 May 2014 06:29:53 -0600

I'm ok if the default time is defined else where.  But  I do believe it
is appropriate to mention that there is a default time to prevent an MA
from continuing indefinitely after losing contact with a Controller.

Charles

-- 

Charles Cook 
Principal Architect
Network

---

From: Sharam Hakimi <[email-masked]>
Date: Fri, 2 May 2014 13:17:36 +0000

A while back I had proposed that if the MA could not contact the controller in three attempts that it should stop testing until it was able to achieve contact with the controller. The timer for this could be defined elsewhere and can be a user configurable parameter, but I do agree with Charles that a default timer is a good idea so that there is an initial bound.

Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Charles Cook
Sent: Friday, May 02, 2014 8:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] framework comments

Charles

-- 

Charles Cook 
Principal Architect
Network

---

From: <[email-masked]>
Date: Tue, 6 May 2014 13:50:06 +0100

The approach "stop testing if the MA could not contact the controller in three attempts" works if the MA 'pulls' its Instruction from the Controller, but not if the Controller pushes to MA.

> From: Sharam Hakimi [mailto:[email-masked]]
> Sent: 02 May 2014 14:18
> To: [email-masked]; Eardley,PL,Philip,TUB8 R
> Subject: RE: [lmap] framework comments
>
> A while back I had proposed that if the MA could not contact the
> controller in three attempts that it should stop testing until it was
> able to achieve contact with the controller. The timer for this could
> be defined elsewhere and can be a user configurable parameter, but I do
> agree with Charles that a default timer is a good idea so that there is
> an initial bound.
>
> Sharam
>
>
>
> > Since this is an informational framework, I think this document is
> probably the wrong place to define such a default time.
> >
> > phil
> >
> >> Regarding prevention of the MA from continuously executing
> >> Measurement Tasks when contact with the Controller has been lost, I
> >> believe there needs to be a default time.  See inline below.
> >>
> >> Charles
> >>
> >> permanently failed, the MA will stop operating Measurement Tasks if
> >> the MA does not hear from the Controller for a default <tbd> length
> >> of time.  Optionally, the MA can be configured with a specific time
> >> limit; if the MA doesn't hear from the Controller for this length of
> >> time, then it stops operating Measurement Tasks."
> >>
> >>
> >>>>> ...
> >>>>>
> >>>>>> usually associate "transport protocol" with protocols that
> >>>>>> operate at the transport layer, like TCP and UDP, or with
> >>>>>> protocols like
> >>>> RTP
> >>>>>> what to recommend about this section -- parts seem usable, but
> >>>>>> the way it's described doesn't relate to my understanding of the
> >> nature
> >>>>>> of various protocols.
> >>>> MA (which is the http server). It can be the higher layer Control
> >>>> or Report protocol that dictates which endpoint can or must be the
> >>>> http client/server. For example, TR-069 does allow the TR-069
> >>>> config server to initiate http with the TR-069 client for the
> >>>> purpose of sending a "connect to your config server ASAP" message.
> >>>> But only the
> >>>>> [phil] then there would be two ways of controlling the MA, which
> >>>>> is something we want to avoid.
> >>>> multiple levels here. In my use of the words, a port forwarding
> >>>> rule or mapping is a pinhole. They can be statically (manually,
> >>>> TR-069,
> >>>> Pinholes dynamically generated by the NAT or firewall processes as
> >>>> a result of outbound TCP or UDP packets don't tend to be
> considered
> >>>>  send keepalives, such as those of the STUN protocol [STUN],
> >>>> towards the Controller to keep open the pinholes (and perhaps use
> >>>> these also as a network reachability test).
> >>>>
> >>>> I recommend referencing UPnP IGD, and not just UPnP. And calling
> >>>> the protocol described in TR-069 "CWMP".
> >>>>>> Comment: This is not necessarily true if it is possible for the
> >>>>>> MA not to be located in a place where it is associated with a
> >>>>>> single
> >>>> end user
> >> Tel:  303.992.8952  Fax:  925.281.0662 [email-masked]
>
> --
>
> Charles Cook
> Principal Architect
> Network

---

From: Sharam Hakimi <[email-masked]>
Date: Tue, 6 May 2014 19:52:47 +0000

I do not believe that Pull/Push would have an effect as the existence of the controller is checked by the MA after the MA has its instructions. It could be a simple ping of the controller while the instructions are in effect. We could make it more complicated if desired later.

Sharam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 May 2014 23:42:50 +0200

On Tue, May 06, 2014 at 07:52:47PM +0000, Sharam Hakimi wrote:

> I do not believe that Pull/Push would have an effect as the
> existence of the controller is checked by the MA after the MA has
> its instructions. It could be a simple ping of the controller while
> the instructions are in effect.

A ping only tells you that something uses a given IP address (or an IP
address derived from a DNS name). This is not really the same as "I
can talk to my controller" or "my controller can talk to me". Hence, I
believe an MA should shut down if communication between the MA and the
controller has not taken place for a certain amount of time. (It could
be that for example the security credentials get out of sync - in that
case, you still may want to shut down after say a months or a year.

/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/>