Re: [Adslmib] Next Generation ADSL (ADSL2) poll

["Clay Sikes" <[e-mail]>]

Bob,

When it is ready for comments, I plan to provide input.  Paradyne currently using an enterprise MIB module based on an interpretation of an early version of TR-090.  My take is that an IETF MIB module is needed to support ADSL2 and ADSL2plus.

My understanding is that there were some actions items from the 62nd IETF meeting.  I have indicated what I thought the actions were in blue below.

Thanks for moving this forward!

Best Regards,
Clay

ADSLMIB Working Group - Minutes
62nd IETF, Minneapolis, MN USA
March 7, 2005

2.  Faye noted that the draft and TR-090 do not support a
method of connecting multiple channels to the interface MIB.
She suggested that we petition IANA to provide another ADSL
interface type, adsl_channel, in addition to the ones
already assigned (fast and interleaved). 

Moti noted that while the model uses an index to identify
the channel in question, that he was not adverse to having
another interface type layered into the draft.  The attendees
agreed to "take it to the list".

3.  Faye pointed out a problem with multi-channel bandwidth
limitation, stating that the summation of the available
maximum bandwidth allocations should be equal to the maximum
available on the line.  Otherwise, it was an "oversubscription"
issue. 

Bob Ray pointed out that the aggregate maximum-per-
channel bandwidth (sum of channels) defined in the channel
as line impairment would render useless any assignment.

Moti stated that this discussion was pointless in that,
in his opinion and experience, no one ever subdivided an
adsl line is this way; that it was over-engineering, a
solution in search of a problem.

The chair urged the issue be "taken to the list".

4.  Faye mentioned that the draft does not maintain separate
objects for ATU-C and ATU-R as RFC 2662 does.  She argued
that having them separate was "nicer".  Moti said that the
use of the word "nicer" was subjective and he wouldn't try
to base a decision on it because of that.  Bob Ray noted that
the approach of using an index has been used in the RFC 3276
and RFC 3728. 

The chair urged the issue be "taken to the list".

7.  Faye commented that the name of Moti's draft needed to be
better than "next generation", or "ng".  Moti stated that he
didn't want to name it adsl2 as that implied restrictions as
to the scope of adsl variants the draft might address. 

Faye suggested that the issue be "taken to the list" and all
concurred.

8.  Faye again mentioned the lack of separate objects for
ATU-C and ATU-R, stating that having another index object
made it difficult to implement RFC 3276.  "Too many indices".

In response, Moti asked if there were any implementation reports
on RFC 2662 [note: a working group milestone that should be
addressed very soon now].  There was mention of two or three.

9.  Moti then discussed things that are missing in his draft.
    - test management support.  Moti is adamant that "tests"
      and "diagnostics" are distinct.  Faye asked pointedly
      if there is any user data being passed when a diagnostic
      is being run. 
    - sub-carrier snr measurement time.
    - psd masks.

Moti stated that these omissions were not because he didn't think
they should be omitted, rather that that they were complex and
required more thought.

Faye suggested that the issue about interface status during
diagnostics (up, down, under test) be taken to the list.

10. Moti briefly discussed the data returned by the diagnostics
and that it made sense, in his opinion, to have them returned
as OCTET STRINGs of fixed size rather than have an index.  It was
agreed that this was the better approach (given the overhead
associated with walking an array of bytes).  It was also noted
that the bit ordering within these values needs to be specified
in the draft.

11.  Faye noted that if the draft used ifIndex for channel
identification (see note 2, above), that Moti's "templates"
would not be needed.  Moti commented that "profile" and
"template" mean the same thing in the draft.

When Moti and Bob didn't understand how channel templates
wouldn't be needed, Faye agreed to produce an example illustrating
her point.  "On the list".

12.  There was a brief discussion as to whether the draft needed
to address ATM objects.  It was decided to leave this "for the
list".

On 4/8/2005 9:10 AM, Ray, Robert wrote:

[e-mail]" type="cite"> Next Generation ADSL (ADSL2) poll

Moti and Menechem's draft for ADSL2 is available online at:

http://www.ietf.org/internet-drafts/draft-morgenstern-ngadsl-mib-00.txt" rel="nofollow">http://www.ietf.org/internet-drafts/draft-morgenstern-ngadsl-mib-00.txt

I need a show of hands from the working group community as to who,
is interested in this work, who will contribute to this work, and who plans
on using the product of this work.

Having only three attendees in Minneapolis for Moti's presentation was
not a very convincing display of interest.

Please respond, to the list (not just to me), as soon as you can.

Bob Ray

_______________________________________________
Adslmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/adslmib" rel="nofollow">https://www1.ietf.org/mailman/listinfo/adslmib
  

_______________________________________________
Adslmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/adslmib