Re: [manet] MANET Protocol Applicability

[Abdussalam Baryun <[e-mail]>]

Hi Stan,

Please note that I needed to discuss this issue because it was not
understood and left open by the chair at WG 82 meeting to be discussed
at the list, which was not much discussed. I have noticed Mr.Perkins
mention the word dangerous in 82 meeting, and now you mention it
again. I need to know how kind or what type of dangerous you mean
please define it and what will be result of the work proposed by
Mr.Cole,

Please see in lines comments:

On 6/8/12, Stan Ratliff <[e-mail]> wrote:
> It's been said by others on this mailing list, but I'll add my opinion in as
> well:  Any attempt to specifically define L2 technologies for MANET networks
> is, IMO, misguided at best, dangerous at worst.
>

AB> traveling by airplane may be dangerous but still many people
travel this way, driving a car may be dangerous but still most of
people use it. Therefore, what kind of dangerous you are seeing that I
can't see.

> In my experiences, we have deployed mobile networks over a variety of L2
> technologies; that is *exactly* what the layered model (what you are
> referring to as the abstraction) was intended to facilitate. The L1/L2
> characteristics of the networks I've worked on varies wildly - again, a
> benefit of the layered approach. Part of the DLEP work is trying to find
> ways for radios and routers to tell each other more information (thus, to
> some extent, DLEP codifies a small subset of "layer violations", if you
> will), but to do so in a manner that is applicable for all types of devices.
> Hence, the generalized DLEP abstractions for "bandwidth" and "latency".
>

Do you admit now that DLEP is a L2 technology or you think it is not.
I think we thought of the proposal of Mr.Cole only because of the new
DLEP ideas and/or other R2RI ideas bring to MANET.

> So this email can be registered as my vote as a Working Group member that
> this (a) is a *really bad* idea, and (b) should not be accepted as a working
> group item, if it is presented to the WG.
>

I thank you for your vote and opinion and really that is why I am
writing my posts to see if it is worth it or not by the community
feedback  :), Please all WG give me your feedback before and then if I
feel there is a need I will take my chances


Best Regards
Abdussalam
==================================================
>> Hi Chris,
>>
>> I thank you for your comments. I agree with Teco. However, your
>> comments look in one direction, but I want to see All directions if
>> possible. Your comments see the protocol progress in ignoring L2
>> because abstract layer, which I admit I like and we still SHOULD do
>> that now and in future because it gives better performance (the
>> Designer-point-of-protocol).
>>
>> In the other direction is that the customer wants to know our
>> assumption/conditions or L2 technologies that we use as
>> possible-use-case or defined in the section of
>> Protocol-Applicability-Statement, so s/he can know how to use it OR
>> s/he can understand that the DESIGNER tested the condition or
>> scenarios of using PROTOCOL over such technology (the
>> customers-point-of-using-protocol). We have different users around the
>> world with different network technologies in use.
>>
>> We have to admit that RFC3561 and RFC3626 were not general purpose
>> enough to cover LLN issues which that is why we have a WG named ROLL
>> (i.e. 4 years old) and that is why we have AODVv2 and OLSRv2.
>>
>> We SHOULD be more practical as Mr.Clausen mentioned in WG-77-meeting
>> (i.e. his input regarding one protocol that only was tested by
>> simulation scenarios), theories don't give right results. This was
>> also spoted by Corson (1998), it seems that is why he written the
>> draft, and that is why I think the importance of their both inputs.
>> Please note that NOT mentioning some technology definitions in the
>> applicability of protocol, doesn't mean that the protocol is really
>> tested as a GENERAL purpuse protocol (e.g. OLSRv2, AODVv2). Our
>> protocols are tested in some industry technology and are not in
>> others.
>>
>> Please note that MANET WG is doing OLSRv2 without updating RFC3626
>> which make people think why?, I want to define technologies at L2
>> because DLEP is important for my draft, and that for DSRv2 to be
>> reasonable to users around the world, and to get feedback from time to
>> time of their concerns so I can update some RFC in future (if I was
>> successful : ), each 8 years or any reasonable requirement.
>>
>> Best Regards
>>
>> Abdussalam Baryun
>> University of Glamorgan, UK
>> =======================================================
>> < One may be wrong, or may be right, but it does not matter if we work
>> together
>> as a group to discuss and resolve all issues. IETF WGs are always right >
>> ****************************************************************************************
>> This email and any attachments are confidential to the intended recipient
>> and may also be privileged. If you are not the intended recipient please
>> delete it from your system and notify the sender. The contents are comply
>> to the IETF regulations, and WG procedures. You should not copy the
>> email nor use it for any purpose other than IETF procedures purposes.
>> ****************************************************************************************
>>
>>
>> On 6/8/12, Dearlove, Christopher (UK) <[e-mail]>
>> wrote:
>>> Being explicit about L2 technologies is exactly what MANET should not do.
>>> At
>>> least not in any limiting way. Of course if someone were to write an
>>> informative draft about (say) using OLSRv2 over IEEE 802.11 that would
>>> be
>>> fine. Though it would run the risk of suggesting to some that that is
>>> the
>>> only L2 suggested,, so I'd want the draft to make it clear that wasn't
>>> so.
>>> And anything that said OLSRv2 was intended for use over the following L2
>>> protocols would be completely wrong. The point of routing at L3 is to be
>>> as
>>> L2 independent as possible.
>>>
>>> If I've read the draft you mention it was a long time ago. Digging up
>>> 1998
>>> drafts to reissue doesn't strike me as the most productive possible
>>> exercise.
>>>
>>> --
>>> Christopher Dearlove
>>> Senior Principal Engineer, Communications Group
>>> Communications, Networks and Image Analysis Capability
>>> BAE Systems Advanced Technology Centre
>>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>>> Tel: [phone] |  Fax: [phone]
>>> [e-mail] | http://www.baesystems.com
>>>
>>> BAE Systems (Operations) Limited
>>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
>>> Centre,
>>> Farnborough, Hants, GU14 6YU, UK
>>> Registered in England & Wales No: 1996687
>>>
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of
>>> Abdussalam Baryun
>>> Sent: 08 June 2012 04:42
>>> To: manet
>>> Subject: [manet] MANET Protocol Applicability
>>>
>>> ----------------------! WARNING ! ----------------------
>>> This message originates from outside our organisation,
>>> either from an external partner or from the internet.
>>> Keep this in mind if you answer this message.
>>> Follow the 'Report Suspicious Emails' link on IT matters
>>> for instructions on reporting suspicious email messages.
>>> --------------------------------------------------------
>>>
>>> Hi Folks
>>>
>>> I have read two important inputs and want to share my opinion,
>>>
>>> ============  point 1  ============
>>>
>>> In one work in progress ietf-draft (expired):
>>> draft-ietf-manet-appl-00.txt,
>>> Corson, (1998)mentioned in Abstract and Introduction:
>>>
>>> Abstract> The intent of this 'Applicability Section' is to
>>> aid readers unfamiliar with the details of each protocol's design in
>>> understanding the protocol's basic characteristics, functioning and
>>> mechanisms, as well as to provide a general description of the
>>> networking context for which the protocol was designed, and in which
>>> it is expected to perform well.
>>>
>>> Introduction> The set of applications for which the use of MANET
>>> technology envisioned is diverse, ranging from small,
>>> energy-constrained nearly
>>> static networks to large-scale, mobile, highly-dynamic networks. The
>>> combinations of network size, topology composition and dynamics,
>>> bandwidth and energy availability, physical and link-layer
>>> technologies, intended application usages, etc. are many, and it seems
>>> unlikely that a single protocol will function superiorly over this
>>> wide range of networking contexts. Thus a given protocol is likely to
>>> be well-suited for operation in those networks whose characteristics
>>> match well with the combination of mechanisms employed by the
>>> protocol.
>>> ============  point 2  ==============
>>> In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is
>>> important to be explicit about assumptions/conditions before talking
>>> about protocol.
>>> ============  opinion  ==============
>>> I agree with both points and approach to solve routing protocols, and
>>> would RECOMMEND either of the following:
>>> 1- MANET WG defines (in one informative-draft) intended application
>>> usage, and be explicit about applicable L2 network technologies. So
>>> that each future protocols mentions in their applicability statement
>>> section the usual use-case for such protocol, OR
>>> 2- MANET WG renews the I-D expired of Corson (1998) and adds more
>>> issues so it can become an RFC in future,
>>>
>>> Thanking you,
>>> Abdussalam Baryun
>>> =========================
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>> ********************************************************************
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. If you are not the intended
>>> recipient please delete it from your system and notify the sender.
>>> You should not copy it or use it for any purpose nor disclose or
>>> distribute its contents to any other person.
>>> ********************************************************************
>>>
>>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>
>