Re: [rbridge] OAM direction

Vishwas Manral <vishwas.ietf@gmail.com> Sat, 31 March 2012 23:04 UTC

Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268CA21F87CC for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Sat, 31 Mar 2012 16:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.45
X-Spam-Level:
X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[AWL=1.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIZdW3MUrjpx for <ietfarch-trill-archive-Osh9cae4@ietfa.amsl.com>; Sat, 31 Mar 2012 16:04:43 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E486121F87B0 for <trill-archive-Osh9cae4@lists.ietf.org>; Sat, 31 Mar 2012 16:04:43 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q2VMSTrc004448; Sat, 31 Mar 2012 15:28:30 -0700 (PDT)
Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q2VMS5Zh004407 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rbridge@postel.org>; Sat, 31 Mar 2012 15:28:14 -0700 (PDT)
Received: by obbwd18 with SMTP id wd18so3897434obb.39 for <rbridge@postel.org>; Sat, 31 Mar 2012 15:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XZtRqKHZQ3UfegzVf62ndo5ezrq+aReSgzQPBfT+sZI=; b=L9ZNUmY8eBuqZd1SLUuKcYcs4W9kIBBNGafC1VzX8bP7/fY3OLAeizVuA91/frz0X7 FHHbXq/zOwQbUcU88mVx4/oj6fsPt2zLEMAKgydKsfT2FFpfQ+xw4ObhKqWHr84KbAR8 ThIgT9+6HmWSQitEfZeRVSLDan/sIfOWEbXB9EjnXtFgADh0rrEuq0V9G4PWcqrp6+Br s5oUVpUVlsr3tjdd/y0kD0TeGeYwmuE8oHdGUFXHIcaqVfxlYpQ0PU2zq1tG6DLMN35n 1oehAo3x0vbcK6OfNBL0ucO2OCKZNGXL3gZcN9wUjVHhP+GQzD5MuXTN5jp3mOQ9jNRD Q8Tw==
MIME-Version: 1.0
Received: by 10.60.4.162 with SMTP id l2mr4609362oel.3.1333232885174; Sat, 31 Mar 2012 15:28:05 -0700 (PDT)
Received: by 10.182.134.73 with HTTP; Sat, 31 Mar 2012 15:28:05 -0700 (PDT)
In-Reply-To: <CANbjNQFrXaYa7db8jJz5Vwi1Wf9iiMaBWNa+TUtye36J74gPow@mail.gmail.com>
References: <CAOyVPHTPWb=nJnwTyuBZorbsXsNJh2kPND9AxgDGnbLSF5iDfQ@mail.gmail.com> <CANbjNQFrXaYa7db8jJz5Vwi1Wf9iiMaBWNa+TUtye36J74gPow@mail.gmail.com>
Date: Sat, 31 Mar 2012 15:28:05 -0700
Message-ID: <CAOyVPHTdR7yVZtkJMNJwF5+OfEjgrsVakQtYPuRkUELKGa9E7A@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Jon Hudson <jon.hudson@gmail.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: vishwas.ietf@gmail.com
Cc: Sam Aldrin <aldrin.ietf@gmail.com>, "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>, "rbridge@postel.org" <rbridge@postel.org>
Subject: Re: [rbridge] OAM direction
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1425931180=="
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org

Hi Jon,

I am saying one OAM mechanism, which can allow us to run over multiple
layers, With a particular layer binding done to start off. The mechanism
should be independent of the lower layer and that should allow it to be
extensible for the future.

If you see we can already do reach ability tests from server to server (so
ICMP Ping), as it traverses a TRILL network, or even a Server to Router
test.

Let me know if I am missing the point altogether?

Thanks,
Vishwas

On Sat, Mar 31, 2012 at 3:14 PM, Jon Hudson <jon.hudson@gmail.com> wrote:

>
> That's an interesting point Vishwas. I think I was too sleepy when I first
> read this. To be able to choose to run OAM over whatever layer I choose in
> TRILL would be highly desirable.
>
> So then what you are saying is that while the end goal is to support
> multiple options for OAM transport, for the sake of moving forward the goal
> should be to choose a simple direct example for the draft so that we have
> an example of ping and traceroute.
>
> Then the end goal would be the ability to perform OAM function over
> whatever transport was being tested in that case.
>
> Is that correct?
>
> On Sat, Mar 31, 2012 at 11:48 AM, Vishwas Manral <vishwas.ietf@gmail.com>wrote:
>
>> Hi Jon,
>>
>> Here are a few points we need to take care for good OAM design:
>>
>> 1. The OAM packets should be defined as far as possible to be independent
>> of the lower layer.
>>
>> 2. As we know we already run OAM over all layers like TCP/ ICMP/ UDP/ IP
>> or any thing else, so as to be able to replicate real world traffic.In a
>> TRILL network, we can already run traffic/ OAM end to end. So if we sent
>> IP/ ICMP ping over the TRILL network end-to-end, it would work similar to
>> similar data traffic already. What is most required is how the OAM traffic
>> is able to monitor traffic directly over Ethernet.
>>
>> 3. We do not need to define every possible combination of OAM packets in
>> the same draft. We first need a simple set of ping and unicast traceroute.
>>
>> Do let me know if this sounds reasonable?
>>
>> Thanks,
>> Vishwas
>>
>> On Sat, Mar 31, 2012 at 3:05 AM, Jon Hudson <jon.hudson@gmail.com> wrote:
>>
>>>
>>> The number one concern I hear from Users about anything UDP is that it
>>> can be dropped and is stateless. (big issue with VXLAN) As this is the same
>>> for ICMP I see no practical difference to the User which one is used.
>>>
>>>
>>> On Fri, Mar 2, 2012 at 10:47 AM, Sam Aldrin <aldrin.ietf@gmail.com>wrote:
>>>
>>>> Do not have much preference of reusing the same port or not. With a
>>>> programmer hat on, who developed rfc4379 and it's implementation, it will
>>>> be klugy, and have issues when process is/was implemented in h.w. For ex:
>>>> had issue with vccv when used by lsp ping and bfd, due to incompatible
>>>> hardware in the network.
>>>> Having said that, idea is to use similar message or tlv formats, will
>>>> help immensely in adopting the standard.
>>>>
>>>> Cheers
>>>> Sam
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Mar 2, 2012, at 10:11 AM, Vishwas Manral <vishwas.ietf@gmail.com>
>>>> wrote:
>>>>
>>>> Hi Tissa,
>>>>
>>>> I am not sure we would want to use the same port for de-multiplexing
>>>> MPLS OAM and UDP based TRILL OAM packets.
>>>>
>>>> On another note, I do know that folks use different channels for
>>>> testing real application behavior in current networks. So yes UDP based
>>>> channels should be good too.
>>>>
>>>> My biggest concern is that we should not have different message formats
>>>> when the application works over different layers. It is for that reason
>>>> that BFD has been so successful (the same message format/ state machine)
>>>> irrespective of the lower layer protocol.
>>>>
>>>> Thanks,
>>>> Vishwas
>>>>
>>>> On Fri, Mar 2, 2012 at 8:08 AM, Tissa Senevirathne (tsenevir) <
>>>> tsenevir@cisco.com> wrote:
>>>>
>>>>> Dear All****
>>>>>
>>>>> ** **
>>>>>
>>>>> Current draft-tissa-till-oam utilize ICMP extensions defined in RFC
>>>>> 4884. I have also heard preference of using UDP based messaging channel
>>>>> defined in RFC 4379.****
>>>>>
>>>>> ** **
>>>>>
>>>>> Advantage of using RFC 4379 methods is we can utilize the same
>>>>> framework and OAM challenges in TRILL and MPLS world are similar. However,
>>>>> we need to define new TLV series and message types. Question arise whether
>>>>> we should use the same wellknown UDP port used in MPLS OAM or a use a
>>>>> different UDP port.****
>>>>>
>>>>> ** **
>>>>>
>>>>> Advantage of ICMP method is we are utilizing the ICMP infrastructure
>>>>> that is commonly utilized in IP world. However, we need to define RFC 4884
>>>>> extensions and it also heavily depends on acceptance of individual
>>>>> submission draft-shen-traceroute-ping-ext-04.****
>>>>>
>>>>> ** **
>>>>>
>>>>> Would like to see the preference from the WG on specific method over
>>>>> the other ?****
>>>>>
>>>>> ** **
>>>>>
>>>>> Thanks****
>>>>>
>>>>> Tissa****
>>>>>
>>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge@postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> rbridge@postel.org
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>
>>>
>>> --
>>> "Do not lie. And do not do what you hate."
>>>
>>>
>>
>
>
> --
> "Do not lie. And do not do what you hate."
>
>
_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge