Re: [rbridge] OAM direction

[Sam Aldrin <[e-mail]>]

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