[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-bonica-tunneltrace-02
Hi Ron,
It seems that most of what you described are things that you THINK are good to have, but there is no solid technical reason that they MUST be as requirements. By doing so I think you will limit new ideas and innovations. Please see my other comments in-line:
-Shahram
> -----Original Message-----
> From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com]
> Sent: Thursday, February 21, 2002 5:04 PM
> To: Shahram Davari; ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02
>
>
>
>
> > -----Original Message-----
> > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> > Sent: Thursday, February 21, 2002 12:03 PM
> > To: 'Ron Bonica'; ccamp@ops.ietf.org
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > Hi Ron,
> >
> >
> > > -----Original Message-----
> > > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com]
> > > Sent: Thursday, February 21, 2002 11:34 AM
> > > To: Shahram Davari; ccamp@ops.ietf.org
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Sharam,
> > >
> > > Section 7 of this document enumerates a some minimal protocol
> > > requirements.
> > > Specifically, it states that:
> > >
> > > o a traceResponse will carry information regarding a section
> > > of the traced
> > > path
> >
> > Why not information about the whole path? Is it becasue
> GTTP can't do it?
>
> We have a requirement to trace through IP-in-IP tunnels. In this
> environment, no single device knows the entire path. The only
> solution is to
> ask each device, either directly or through a proxy, about
> the hop(s) in
> which it participates.
But a single device could solicit response from other devices on the same path.
>
> >
> > > o a traceProbe will elicit a traceResponse
> >
> > Why not a series of trace responses? Anything fundamentally wrong
> > with it or is it becasue GTTP can't do it?
>
> Given that we must trace through IP-in-IP tunnels, we must
> elicit responses
> from multiple devices. So, when you ask why a single
> traceProbe doesn't
> elicit a series of traceResponses, I assume that you are
> asking why a single
> traceProbe doesn't elicit a series of traceResponses from a series of
> devices.
>
> Let's entertain this possiblity. How could we alert each
> router along the
> traced path to respond to a single probe?
>
> We could specify the IP Router Alert Option on our probe, but
> the presence
> of that option can cause the datagram to follow a different
> path than it
> might otherwise follow. Another possibility is to maintains
> some stateful,
> intermediate proxy that amplifies one traceProbe into many.
> But why do that
> when the probing application is capable of doing the same thing?
a) It reduces the BW usage, b) eleminates connectivity to an outside application,
c) simplifies the application, etc.
What I am trying to say is it is best if you don't put the solution that you think is the
simplest solution as a requirement. Others may have simpler ideas. Perhaps you could add simplicity as a requirement.
BTW, shouldn't scalability be also a requirement?
> Even if you found a neat way to make multiple routers respond
> to a single
> probe, you would still need to deal with out of sequence and missing
> responses.
>
> IMHO, a one-to-one mapping of probe to response is simplest.
>
> >
> > > o UDP will carry traceProbes and traceResponses
> >
> > Why not TCP or even GTTP over IP?
>
> Does TCP add any value when a single probe elicits a single response?
Yes, it could make sure the message gets delivered.
> Putting the protocol PDU over IP is a possibility, but
> protocol identifiers
> are in much shorter supply than UDP port numbers.
But this is not a requirement, it is a suggestion.
>
> >
> > > o the protocol will be stateless
> > > o each device within the trace path need not maintain an IP
> > > route back to
> > > the device that hosts that tracing application
> >
> > Why? Why return path from head of the path is not enough?
> >
>
> In its first version, a route from the head end of the traced path was
> enough. I changed this in response to a comment from the WG.
>
Could you please refer me to such discussions.
> > >
> >
> > > Although these broad brushstrokes do not specify a protocol,
> > > they provide
> > > direction to protocol developers.
> >
> > To develop GTTP!
>
> Or any other protocol that satisfies the requirements.
>
> >
> > We are looking for an IP
> > > based protocol
> > > that can probe network elements about whatever tunnels
> they maintain,
> > > regardless of the tunnel type. We are not looking to extend
> > > the capabilities
> > > of any particular tunneling technology.
> >
> > I know. But the protocol restrictions that are mentioned must be
> > justified.
> >
> > -Shahram
> > >
> > > Ron
> > >
> > > > -----Original Message-----
> > > > From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org]On
> > > Behalf Of Shahram Davari
> > > Sent: Tuesday, February 19, 2002 5:29 PM
> > > To: ccamp@ops.ietf.org
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Hi,
> > >
> > > Although this document is a generic requirement for tunnel
> > > tracing, I find many protocol specific requirements that are not
> > > actually a requirement, rather they are suggesting a
> > specific solution.
> > >
> > > For example:
> > >
> > > "The protocol elicits a series of traceResponse messages."
> > > "Each traceResponse message represents a hop that connects the
> > > head-end of the traced path to the tail-end of the traced path"
> > > "Each traceProbe message elicits exactly one traceResponse message."
> > > "UDP carries traceProbe and traceResponse messages to their
> > destinations."
> > >
> > >
> > > Thanks,
> > > -Shahram
> > >
> > >
> >