Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return

["Andrew G. Malis" <[e-mail]>]

Greg,

I have to admit to not really having read the draft until I saw this
discussion, which got me curious to see what all of the fuss was about. So
I went and read RFC 6374 and this draft, and also 4656.

Given the existence and presumed implementations of 6374, my intuition is
that this draft is a small addition to 6374 to fix a case that that had
escaped the authors at that time. I would bet that if the Return UDP Port
object had originally been included in 6374 to complement the Return
Address object, no one would have batted an eyelash.

Thus, I have no objection to this draft. The time to have discussed a
different approach was during the formation of RFC 6374, not now. Trying to
switch to an approach like RFC 4656 now is an extremely heavyweight fix to
a very small problem.

Cheers,
Andy


On Thu, Jun 12, 2014 at 8:36 PM, Gregory Mirsky <[e-mail]
> wrote:

> Hi Stewart,
> apologize for delayed response.
> I still believe that though defining new TLV that includes both IP address
> and port number is doable it is not the best approach to control MPLS PM
> sessions. RFC 6374 requires control of each and every test/query packet
> thus making some tests impossible to execute (e.g. SLM with smaller packet
> sizes when TLVs has to be used to provide explicit control). I believe that
> extending RFC 6374 with Session Control and Data Fetch commands may be
> reasonable alternative to controlling each test packet explicitly through
> TLVs.
> True, I don't have document that describes the alternative approach at
> this time but would appreciate it be considered and welcome opportunity to
> discuss it in any format.
>
>         Regards,
>                 Greg
>
> -----Original Message-----
> From: Stewart Bryant [mailto:[e-mail]]
> Sent: Wednesday, June 04, 2014 3:29 AM
> To: Gregory Mirsky; MORTON, ALFRED C (AL); Eric Gray;
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
>
> On 25/05/2014 01:14, Gregory Mirsky wrote:
> > Dear Al,
> > thank you for your analysis of the draft and its correlation with the
> LMAP framework.
> > I think that the RFC 6374 gives option for the responder, Measurement
> Peer (MP) in LMAP framework terminology, to send measurement result to an
> arbitrary destination, not only to the Querier, Measurement Agent (MA).
> Yes it does, although as written not to multiple collectors. Do you need
> that? If so I would need to use a modified TLV with the both the address
> and the port since the port will be address dependent.
>
> - Stewart
> >   Though such scenario is not considered for MP in the LMAP framework, I
> believe we can still refer to that node as Data Collector because MA
> instructed MP perhaps based on information received from the Measurement
> Controller.
> > During our discussion Stewart asked if there could be case of multiple
> Data Collectors for the given Measurement Task. That is when I referred to
> the LMAP framework as I believe that it allows to associate  multiple Data
> Collectors with the Measurement Task. Is my understanding correct?
> >
> >       Regards,
> >               Greg
> >
> > -----Original Message-----
> > From: MORTON, ALFRED C (AL) [mailto:[e-mail]]
> > Sent: Friday, May 23, 2014 10:14 AM
> > To: Eric Gray; [e-mail]; Gregory Mirsky;
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return
> >
> > Eric, Stewart,
> >
> > It seems to me (after scanning the draft) that the MPLS-PLDM could be
> treated as the out-of-scope measurement traffic/protocol in the LMAP
> Framework Figure 1 below (Where IPPM is currently used as the out-of-scope
> example):
> >
> >                                                                ^
> >                                                                |
> >                                   Active    +-------------+    IPPM
> >              +---------------+  Measurement | Measurement |    Scope
> >              | Measurement   |<------------>|     Peer    |    |
> >              |   Agent       |   Traffic    +-------------+    v
> >     +------->|               |                                 ^
> >     |        +---------------+                                 |
> >     |              ^      |                                    |
> >     |  Instruction |      |  Report                            |
> >     |              |      +-----------------+                  |
> >     |              |                        |                  |
> >     |              |                        v                  LMAP
> >     |         +------------+             +------------+        Scope
> >     |         | Controller |             |  Collector |        |
> >     |         +------------+             +------------+        v
> >     |                ^   ^                       |             ^
> >     |                |   |                       |             |
> >     |                |   +----------+            |             |
> >     |                |              |            v             |
> > +------------+   +----------+    +--------+    +----------+   |
> > |Bootstrapper|   |Subscriber|--->|  data  |<---|repository|   Out
> > +------------+   |parameter |    |analysis|    +----------+   of
> >                   |database  |    | tools  |                   Scope
> >                   +----------+    +--------+                   |
> >                                                                |
> >
> > The MPLS-PLDM Querier could be co-located with a Measurement Agent, and
> assuming the Querier performs all the coordination, including arranging to
> return the response message to a port co-located with the same Measurement
> Agent (or configuration takes the role of signaling), then the MPLS-PLDM
> responder could be treated as a Measurement Peer.  The LMAP Control and
> Report protocols provision and collect results from the Querier, taking the
> role of a "management system" mentioned in the draft.
> >
> > hope this helps,
> > Al
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Eric Gray [mailto:[e-mail]]
> >> Sent: Friday, May 23, 2014 11:47 AM
> >> To: [e-mail]; Gregory Mirsky; draft-bryant-mpls-oam-udp-
> >> [e-mail]
> >> Cc: [e-mail]; [e-mail]
> >> Subject: RE: [mpls] Comments on draft-bryant-mpls-oam-udp-return
> >>
> >> Stewart,
> >>
> >>      I understand your point.  But the question is not whether or not it
> >> will work, but rather whether or not there is consensus to do it this
> >> way.
> >>
> >>      On any given day, it is trivial to come up with any number of
> >> approaches for doing something (whatever that something is) that will
> >> _work_ - which is not the same as saying that we should all pour
> >> energy into any of those ideas.
> >>
> >>      I also understand the pressures associated with customer
> >> requirements, but don't see why the customer(s) behind your
> >> requirements should have the last word on which approach should be
> >> used - based solely on those requirements.
> >>
> >>      That approach leads to a point-solution that has a definite
> non-zero
> >> cost.  As a general approach, the continuous generation of point
> >> solutions has its own scaling issues.
> >>
> >>      It is my hope that someone will have the energy to put together a
> >> draft to propose an alternative based on LMAP.  I personally do not
> >> have either the energy or the bandwidth.  In fact, I don't have the
> >> bandwidth or the energy to continue in
> >> this discussion.   I sincerely hope and intend this will be my last post
> >> on this topic.
> >>
> >>      If there is insufficient interest in developing the scaled-down
> >> version of an LMAP-based proposal - either within the MPLS working
> >> group, or among the LMAP framework authors - before the Toronto
> >> meeting, or there is not a number of like objections raised on the
> >> MPLS mailing list, then it would seem that the WG default consensus
> >> is to proceed with your draft.
> >>
> >>      Believe it or not, I personally can live with that.
> >>
> >> --
> >> Eric
> >>
> >> -----Original Message-----
> >> From: Stewart Bryant [mailto:[e-mail]]
> >> Sent: Friday, May 23, 2014 11:18 AM
> >> To: Eric Gray; Gregory Mirsky; draft-bryant-mpls-oam-udp-
> >> [e-mail]
> >> Cc: [e-mail]; [e-mail]
> >> Subject: Re: [mpls] Comments on draft-bryant-mpls-oam-udp-return
> >> Importance: High
> >>
> >> Eric
> >>
> >> I think the onus is on you as the objector to provide me with a
> >> pointer to a specific protocol alternative not a framework, or to
> >> show why this simple addition of four bytes will not work in the manner
> that I describe.
> >>
> >> Stewart
> > .
> >
>
>
> --
> For corporate legal information go to:
>
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>