Subject: RE: Draft MPLS minutes

From: Shahram Davari <[email-masked]>
Date: Thu, 3 Apr 2003 07:45:25 -0800

>
>         I agree with Curtis; please keep the original text in 
>the draft.
>
>         --Tom

Tom,

Could you please clarify why you think LSP-ping is Simple and efficient? 

The reasons that I think it is not simple and efficient are:

1) Before sending Echo request, you need to run a complicated traceroute to determine the
hash keys (127/8 addresses) that covers all the ECMP points in the path. Also all intermediate nodes need to assign a series of 127/8 addresses to their ECMP path selections.

2) The fact that there are many TLVs defined, means processing the ping/traceroute messages
requires lots of processing power. 

3) It is not clear in the event of a failure how can the Pinged node process all the incoming echo or traceroute messages simultaneously. In other words it seems that it is not
scalable.

4) LSP ping is a bidirectional transaction and therefore requires 2x BW compared to
a unidirectional transaction. So it is not BW efficient either.

Yours,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Thu, 3 Apr 2003 08:30:11 -0800

I am tired of this . Do what ever you like.

-Shahram

>-----Original Message-----
>From: Curtis Villamizar [mailto:[email-masked]]
>Sent: Thursday, April 03, 2003 11:11 AM
>To: Shahram Davari
>Cc: [email-masked]'; 'George Swallow'; [email-masked]
>Subject: Re: Draft MPLS minutes 
>
>
>
>In message 
><[email-masked].
>ca>, Shahram Davari writes:
>> >I remember that earlier discussion very well and your 
>objection to the
>> >words "simple and efficient" included the argument that these words
>> >added nothing to the draft.  I suggested that it could be removed on
>> >the grounds that it added nothing but I did not agree that it the
>> >protocol could not be described as "simple and efficient".
>> 
>> I am sure that is true specially after the ULTRA simple ECMP handling
>> text that you suggested to be added to the draft !
>> 
>> >I am also
>> >not an author of this draft.  Apparently the authors did not agree
>> >since the words "simple and efficient" are still in the -02 draft.
>> 
>> You are right, I thought it was agreed on the list that this 
>text be removed.
>> Also please note that any change to any WG draft MUST be 
>done based on WG
>> consensus. So I am not sure that the authors personal 
>opinion should override
>> WG consensus.
>
>I suggested the change to appease one vocal complainer and said so
>when I suggested it.  My wording was:
>
>> I'm not suggesting comments should be ignored.  For example:
>> 
>>    This document describes a mechanism that can be used to 
>detect data
>>    plane failures in MPLS LSPs.  The mechanisms described here are
>>    intended to detect forwarding faults in an MPLS LSP which prevent
>>    traffic from being delivered to its intended destination and
>>    isolate the fault to the LSR at which traffic stops flowing.  No
>>    attempt is made to determine that cause of the fault or diagnose
>>    problems any further.  Enumeration of all possible fault types is
>>    outside the scope of this document.
>> 
>> Removing "simple and efficient" in the first sentence 
>addresses a long
>> message voicing an objection.
>> 
>> The last two sentences address some diatribe on this list about
>> lsp-ping != Y.1711 by agreeing that lsp-ping != Y.1711.  Its a
>> feature.
>> 
>> I think a lot of comment resulted from a poor understanding of how
>> traceroute mode was supposed to work.  I responded earlier by saying
>> that "like IP tracroute" was sufficient for me but needed to 
>be in the
>> document.  So we'll put it there.
>> 
>> There was a lot of noise on this list.  If there were useful
>> comments that were missed they can be repeated.
>
>No one else spoke in favor of the change.  I was not in favor of the
>change but was tired of hearing your complaining.  That leaves you
>alone and the apparent consensus is to keep that wording as is.
>
>I suggest that both you and I now stop and listen for consensus on the
>list.
>
>> >Since the second sentence is not true it should either be 
>omited from
>> >the minutes or a note added that the statement though made was not
>> >true.  The authors neither agreed that the protocol is not 
>simple and
>> >efficient nor did they remove the text.
>> 
>> First of all this is a minute of what happened in the meeting, not an
>> analysis or debate document. You are free to comment on the list, but
>> I don't think changing the minutes of what actually was said 
>is the right
>> thing to do. However, if you like to introduce such 
>precedence, then I have
>> a bunch of comments against many comments raised during the 
>meeting that 
>> I would like to be added to the minutes.
>
>Maybe you don't care if your statement is true.  I'll leave it to the
>minute takers/keeper as to whether to footnote the statement.  I don't
>think it matters either way.
>
>> -Shahram
>
>Curtis
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 03 Apr 2003 11:49:21 -0500

>hash keys (127/8 addresses) that covers all the ECMP points in the path. 
>Also all intermediate nodes need to assign a series of 127/8 addresses to 
>their ECMP path selections.

         I think you are confused about how it works.  You don't need to do 
a trace
before you can send an Echo request nor do you need to know the hash
keys a priori.

>requires lots of processing power.

         That is an incorrect assertion. Ask anyone who has implemented
it.

>3) It is not clear in the event of a failure how can the Pinged node 
>process all the incoming echo or traceroute messages simultaneously. In 
>other words it seems that it is not scalable.

         I think you need to be more specific (i.e.: give a detailed example).
Throwing around the "not scalable" flag doesn't cut it.

>a unidirectional transaction. So it is not BW efficient either.

         So. MPLS is unidirectional inherently connection-less,
thus LSP ping mirrors this behavior nicely.  There may not be
a reverse path from any node to the one in question because
no reverse path (via MPLS) may exist.  I think you are assuming
that a bi-directional LSP exists, in which case I assert that you
should test both.  In this way it is simple and elegant.

         --Tom

>-Shahram

http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X

---

From: "David Allan" <[email-masked]>
Date: Thu, 3 Apr 2003 14:54:34 -0500

Guys:

1) I'm not aware of anywhere where the minutes are subsequently annotated to
provide a critique of a speakers statements. Which is what started this
thread. So lets drop that turd.

2) "Rough consensus" and running code seems to suggest that the WG does have
some input into WG documents. So lets drop that one as well.

cheers
Dave

> From: Shahram Davari [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2003 2:10 PM
> To: [email-masked]'
> Cc: [email-masked]
> Subject: RE: Draft MPLS minutes 
> 
> 
> 
> >Your  citation from  RFC 3160  does not  seem to  imply
> >anywhere  that every
> >change to a WG draft must  be approved by consensus.
> 
> It says:
> 
> "     2. Receive comments on the draft
>       3. Edit your draft based on the comments"
> 
> It never says edit the draft as the author(s) wish.
> 
> 
> >In fact,
> >your citation
> >doesn't  even mention  consensus.
> 
> True, but I think that is common sense that when a draft is a 
> WG document, the author(s) should not change it based on their own 
> opinion only. Otherwise what would be the difference between 
> a WG draft and a personal draft?
> 
> >Not to  mention  that RFC
> >3160 does  not
> >specify the standards process anyway.
> 
> So? we are talking about WG drafts.
> 
> -Shahram
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 3 Apr 2003 12:20:56 -0800

>before you can send an Echo request nor do you need to know the hash

I think you need to read the draft again. Here is what is says:

"  An ingress LSR periodically sends an MPLS
   traceroute message to determine whether there are multipaths for a
   given LSP.  If so, each hop will provide some information how each of
   its downstreams can be exercised.  The ingress can then send MPLS
   echo requests that exercise these paths.  If several transit LSRs
   have ECMP, the ingress may attempt to compose these to exercise all
   possible paths."

>Throwing around the "not scalable" flag doesn't cut it.

That was the example I gave. In the event of a failure many LSP sources
would detect a loss of connection and would initiate diagnostics. They all simultaneously
would run traceroute and possibly more ping to diagnose the failure. The LSRs therefore
may need to process hundreds or thousands of traceroute/ping messages simultaneously.

>
>>4) LSP ping is a bidirectional transaction and therefore 
>requires 2x BW 
>>compared to

What I meant was that in LSP-ping it is the ingress that detects the
failure not the egress. And for ingress to detect the failure you need
to return the echo response while if egress was to detect the failure
you wouldn't need to consume twice more BW to continuously return echo
replies.

-Shahram

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Fri, 4 Apr 2003 17:49:19 -0600

This is an excellent set of minutes in general, and the VoIP header compression discussion is a very good and complete summary.  

In regard to the item:

> Requirements for End-to-End VoIP Header Compression
> http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt
...
> The main issue is finding the right home for this work - some people
> believe that the MPLS WG is the right place, and the authors would
> like to propose that this is the right place.
>
> Scott wanted to make sure that the authors were aware of the robust
> header compression work ongoing in the transport area.  The answer is
> yes.  In fact, the primary author of that work (Steve Casner) also
> thinks this work belongs in the MPLS WG.
>
> George and Scott agreed that this will be brought up in the Sub-IP
> Directorate meeting.

Please let us know the status of the discussion on the MPLS WG charter extension.  

Hopefully we can get agreement that this work can be brought within the charter of the MPLS working group.  Please let us know how we can assist in getting a positive resolution.

We have followed the 'MPLS Change Process' http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt and are awaiting the next steps.  We certainly do not want to force this into the 'dust bin'.  Based on the criteria in the Change Process, it should go forward: there has been support from other service providers, quite a lot of discussion/support on the lists, and even prior interest/acceptance in the WG.

Thanks,
Jerry