Re: [Tsvwg] IETF 62 Proceedings - TSVWG meeting (can be updated)

["James M. Polk" <[e-mail]>]

Chairs

I'm not sure I agree with the minutes regarding the (heated) MLEF Concerns 
discussion. I believe I agreed with Scott when he said this is a worthy 
document to move forward *IF* it were broadened to a larger problem area 
than just the US Gov's desire for MLEF for MLPP networks.

I believe what was agreed was that I (with Fred) would rewrite the Intro 
and conclusion sections of the ID to make its applicability wider, but that 
the core of the ID was on the right track. Obviously there will need to be 
a review of the core of the ID if the rewritten sections change what should 
be in the core of the doc.

comments

BTW - you hid the Paris comment well, as I haven't found it yet

At 11:48 AM 4/8/2005 -0700, Allison Mankin wrote:

>Transport Area WG (tsvwg)
>
>Monday, March 7 at 1530-1730
>=============================
>
>CHAIRS: Allison Mankin <[e-mail]>
>         Jon Peterson   <[e-mail]>
>
>
>MLPP Update (Fred Baker/James Polk) (15 mins)
>
>Four drafts.
>
>First, the MLEF concerns draft has been posted as a WG document
>pursuant to discussion last time.  This changed the draft handle only.
>
>Second, our MLPP proposal which is RSVP based.  We did a minor update
>and submitted as a WG draft.  There were errors in the appendix with
>respect to SIP call flows; they have been fixed.  Other than that
>it's the same.
>
>Third, at last meeting, James talked about RSVP bandwidth reduction thing.
>This identified a bug in RFC 3181 when it comes to dealing with aggregate
>reservations.   If I need to preempt call within reservation, it has me
>tear down and set up with new number.  This has a giant hole...
>this draft suggests that one simply reduce bandwidth.  "accept if doesn't
>exceed X", and the endpoint changes codec or whatever is the right thing.
>This draft considers backwards compatibility.
>
>Fourth, the last draft, is a use case for bw reduction thing.
>A VPN network with multiple levels of VPNing.  This is still
>an individual submission.    The draft posits that VPN router
>might be two boxes.  Talk about what crosses the private interface
>between them.
>
>
>The other 3 pretty sure about.  This one needs work; dinner tomorrow
>night is a discussion of this draft with others that are interested.
>
>we want:
>
>We want the first three to move forward.
>mlef-concerns -> informational
>mlpp that works: informational or BCP
>bw-reduction -> proposed.  it's a protocol.
>
>As to the last one... If the way we get people to read & comment
>is to go to last call, I would like to go to last call.  We
>want people to read & comment.  So LC to informational?
>
>Mike Pierce: object vehemently to MLEF concerns going anywhere.
>The MLEF concerns document is to object to and provide comments on draft
>that myself and Steve Silverman wrote on MLEF.  We have seen it..
>and responded to it two years ago.  We have made changes.
>To show you how bad it is... look in the draft reference section.
>It references the Jan. 2004 version that has concerns with.
>However, the MLEF document has been revised twice, and this draft
>doesn't reference updates, much less recognize modifications made to MLEF.
>
>The MLEF concerns actual title is
>"MLEF without capacity admission does not satisfy MLPP requirements",
>but we said that from the beginning.
>The version from way back when that was referred to... included
>explicit statement that it would not work without call admission control.
>We strengthened that statement.  Yet this doc keeps arguing that point.
>
>In addition, this document contains a large number of technical inaccuracies.
>For example, g709 increasing throughput in face of loss.
>It is theoretically possible for a codec to do that, but this one doesn't.
>It talks about having 3 specific rates...
>
>Jon: don't want to take exception, but this is a more detailed discussion
>than we have time for.
>
>But we need to have the discussion.  Mike objects to the document
>proceeding, and is not sure how it to WG status; his recollection is
>that there was no agreement.
>
>Jon believe there was consensus, and the first time that Mr. Baker
>spoke to us about it, there was strong consensus for this work.
>
>James Polk: to last point, about ILBC not being variable...
>Alan Durek wrote part of that.  He is the author of that protocol.
>He is who helped write section.
>
>Mike said it's not in rfcs, though.
>
>Scott Bradner agreed that this particular document that was reviewed
>at ieprep was a very important document in it's day.  However, he's
>not sure if needs to be RFC, unless it is recast as
>"concerns about non-admission controlled attempts at priority".
>It is an instructive document, but not sure it deals with the alternatives
>on table today.  Would agree that it should fade out, but strongly support
>moving the others forward.
>
>Jon asked for Fred to comment.  Fred stated that when the
>document was first published, he didn't expect it to be an RFC.
>He could go either way.
>
>James said that one of reasons why we regenerated  this six months
>ago or so is that we had a couple other customers, other than us government,
>that wanted to promote diffserv-based QoS using that mechanism.  So we wanted
>to have the concerns documented.  He agreed with Scott that the
>scope ought to be broader.
>
>Fred said that he heard that if this document is to become an RFC at all,
>the working group must tell him what to see.
>
>Jon said that he believed the working group requested that rather than
>document the problems with a specific proposal, speak to general design
>principles that are objectionable.
>
>Scott agreed.
>
>Jon noted that we are out of time; clearly there should be more discussion
>on issues.  Jon invited Mike to bring technical objections to list.  Jon
>then declared the meeting to be closed.
>
>
>
>------- End of Forwarded Message
>
>
>_______________________________________________
>tsvwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/tsvwg


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

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