Re: [rbridge] OAM direction

[Vishwas Manral <[e-mail]>]

Thanks Sam. Sounds great to me.

-Vishwas

On Sat, Mar 31, 2012 at 3:32 PM, Sam Aldrin <[e-mail]> wrote:

> Hi Vishwas,
>
> I will let Tissa to fill you in with details.
>
> But we had lengthy discussions about the same here at IETF and the
> conclusion was opposite to what you have eluded to. We had laid out bare
> all the various proposals, I believe it is 3, on the table and had all the
> stake holders involved. The conclusion was that, we had to formalize the
> requirements first and ensure all the identified requirements to be met by
> the proposed solution/framework. On top of it, we were advised to ensure to
> check with other SDO's, in order to ensure the parity and no re-invention
> of the wheel.
>
> HTH,
> Sam
>
> Sent from my iPad
>
> On Mar 31, 2012, at 3:24 PM, Vishwas Manral <[e-mail]>
> wrote:
>
> Hi Sam,
>
> I guess we agree.
>
> All I am saying is, it is good to get the solution out. If you want to do
> the framework in parallel as a guiding principal that's good enough.
> However we should not wait for any framework etc to be finalized before we
> get the OAM solution work going. Infact I think with the way we are, we
> need to proceed with the solution, as we have an idea of the framework in
> place too.
>
> Thanks,
> Vishwas
>
> On Sat, Mar 31, 2012 at 12:59 PM, Sam Aldrin <[e-mail]>wrote:
>
>> Hi All,
>>
>> Whatever tools one implements is left to ones choice. Be it ping or
>> something else. I don't think we are disagreeing on that front at all. The
>> effort we put in here should make sure the framework supports all Oam
>> aspects in Trill. Discussions we had focused on that aspects and resolved
>> many issues, and clarified why we do not have one, at present. Hopefully we
>> put to rest, the confusion, once we publish framework/requirements doc.
>>
>> Cheers
>> Sam
>>
>> Sent from my iPhone
>>
>> On Mar 31, 2012, at 8:48 PM, Vishwas Manral <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]>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 <[e-mail]>
>>>> 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) <
>>>> [e-mail]> 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
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>
>>>>
>>>
>>>
>>> --
>>> "Do not lie. And do not do what you hate."
>>>
>>>
>>
>

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge