Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036

Loa Andersson <loa@pi.se> Fri, 08 October 2004 10:41 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12165; Fri, 8 Oct 2004 06:41:42 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsLu-0003Th-TA; Fri, 08 Oct 2004 06:51:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFs7J-0008H2-Mg; Fri, 08 Oct 2004 06:36:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFs5u-000832-NV for mpls@megatron.ietf.org; Fri, 08 Oct 2004 06:35:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11911 for <mpls@ietf.org>; Fri, 8 Oct 2004 06:35:24 -0400 (EDT)
Received: from oberon.imc.kth.se ([193.10.152.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsFn-0003P9-Jh for mpls@ietf.org; Fri, 08 Oct 2004 06:45:41 -0400
Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.11.6/8.11.6) with ESMTP id i98AVSr18067 for <mpls@ietf.org>; Fri, 8 Oct 2004 12:31:28 +0200
Received: from [127.0.0.1] ([172.16.2.190]) by mail1.imc.kth.se; Fri, 08 Oct 2004 12:33:19 +0200
Message-ID: <41666CE2.8040309@pi.se>
Date: Fri, 08 Oct 2004 12:33:06 +0200
From: Loa Andersson <loa@pi.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: neil.2.harrison@bt.com
Subject: Re: [mpls] For your review - Issues/errors/clarifications in RFC3 036
References: <0536FC9B908BEC4597EE721BE6A353890A9F12E9@i2km07-ukbr.domain1.systemhost.net>
In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F12E9@i2km07-ukbr.domain1.systemhost.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Content-Transfer-Encoding: 7bit
Cc: mpls@ietf.org, ewgray@GraIyMage.com
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Sender: mpls-bounces@ietf.org
Errors-To: mpls-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: 7bit

Neil,

guess that tht is a fair question, it should be looked into,
but I guess that it is out of scope for an update of the
LDP spec. (I didn't say "implemenation specific :) ). For
communication between LDP peers it is my take that we can
trust TCP, after all that was one of the reasons chosing
TCP.

Now, if the protocol exchange information in a correct
manner, but one implementation creates a label mapping
that is errornous, this is not something we can address
in the protocol specification, is it?

/Loa

neil.2.harrison@bt.com wrote:

> Loa,
> 
> I was meaning in general, ie labelled pkts.  Just want to check nothing
> is being overlooked here.
> 
> regards, Neil
> 
> 
>>-----Original Message-----
>>From: Loa Andersson [mailto:loa@pi.se] 
>>Sent: 08 October 2004 11:19
>>To: Harrison,N,Neil,IKR2 R
>>Cc: ewgray@GraIyMage.com; Nick.Weeds@dataconnection.com; mpls@ietf.org
>>Subject: Re: [mpls] For your review - 
>>Issues/errors/clarifications in RFC3 036
>>
>>
>>Neil,
>>
>>are you talking about packets exchange over the TCP 
>>connection between two LDP peers, or (labeled) packets in genral?
>>
>>/Loa
>>
>>neil.2.harrison@bt.com wrote:
>>
>>>Eric,
>>><Snipped>
>>> 
>>>
>>>
>>>>Not if the downstream router sends a label withdraw as an 
>>
>>appropriate 
>>
>>>>recovery response to getting a packet with a label that is invalid.
>>>
>>>
>>>Is there not a possibility that packets might end up at the wrong 
>>>destination for other (defect) reasons?  And in such a case 
>>
>>sending a 
>>
>>>label withdraw seems the wrong action...comments?
>>>
>>>regards, Neil
>>>
>>>
>>>_______________________________________________
>>>mpls mailing list
>>>mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>
>>-- 
>>Loa Andersson
>>
>>Principal Networking Architect
>>Acreo AB                           phone:  +46 8 632 77 14
>>Isafjordsgatan 22                  mobile: +46 739 81 21 64
>>Kista, Sweden                      email:  loa.andersson@acreo.se
>>                                            loa@pi.se
>>
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                            loa@pi.se

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls