Re: [manet] AB#1 (olsrv2-multitopology): Multiplexing RFC5444 Packets

[Thomas Clausen <[e-mail]>]

My understanding:

Single logical IP hop == "ttl not decremented", in IPv4 terms. 

(An IP-in-IP tunnel may thus appear as one logical IP hop, even though the tunnel spans multiple)

Sent from my iPad

> On 12 Sep 2014, at 13:06, Christopher Dearlove <[e-mail]> wrote:
> 
> The point I think was about the qualifying word logical in stating that 5444 packets only travel one hop. At the IP level that is, nothing to do with 5444's fields.
> 
> But the point is, I don't recall who wanted that word in. But it's irrelevant except as a historical point. What it means is all that matters. And what it basically means is "looks like one hop, and can be used as if one hop, even if physically it uses more than one link. For example we could have a dumb relay in the system. Or use tunnelling.
> 
> -- 
> Christopher Dearlove
> [e-mail] (iPhone)
> [e-mail] (home)
> 
>> On 12 Sep 2014, at 11:54, Henning Rogge <[e-mail]> wrote:
>> 
>> Okay,
>> 
>> are we talking about the "Hop Count" or the "Hop Limit" field in the
>> RFC5444 message header? Or something else?
>> 
>> Henning Rogge
>> 
>> On Fri, Sep 12, 2014 at 12:51 PM, Christopher Dearlove
>> <[e-mail]> wrote:
>>> It's true I don't recall why it (for at least one value of it) was put in. But why something was put in (who had the idea, was it WG consensus or IESG requirement - not the only options) is only relevant to a discussion why we are where we are (as I was making). It has no relevance to where we are, including no difference to anyone implementing.
>>> 
>>> --
>>> Christopher Dearlove
>>> [e-mail] (iPhone)
>>> [e-mail] (home)
>>> 
>>>> On 12 Sep 2014, at 11:26, Henning Rogge <[e-mail]> wrote:
>>>> 
>>>> On Fri, Sep 12, 2014 at 12:15 PM, Abdussalam Baryun
>>>> <[e-mail]> wrote:
>>>> 
>>>>> You could not even remember this week
>>>>> why was logic hop (and many ip hop possibility for packets) put in RFC5444,
>>>> ("You" refers to Christopher Dearlove)
>>>> 
>>>> 
>>>> 
>>>>> Any input from any participant is not wast of time.
>>>> Normally yes...
>>>> 
>>>> but the last two of your post in this thread were a waste of time.
>>>> 
>>>>> I will leave all my other comments for IESG call then.
>>>> 
>>>>> You could not even remember this week
>>>>> why was logic hop (and many ip hop possibility for packets) put in RFC5444,
>>>> 
>>>> I would like to see the relevant quote from Christopher from you.
>>>> 
>>>> (and I would like to know what you mean with "logic hop")
>>>> 
>>>> Henning Rogge
>>>> 
>>>>> which may mean that RFC can wast readers time. The WG draft under my
>>>>> investigation and time, uses the terminology of RFC5444, see the terminology
>>>>> section, therefore if you want to say data packet just say it as you did in
>>>>> your below email.
>>>>> 
>>>>> However, still you need to ensure that packets are having not mixed topology
>>>>> messages. I hope editors respect WG participants even if they think one
>>>>> input is stupid or wasting time.
>>>>> 
>>>>> AB
>>>>> 
>>>>>> On Friday, September 12, 2014, Christopher Dearlove wrote:
>>>>>> 
>>>>>> Every use of the word packet in the draft refers to a data packet being
>>>>>> routed, not a 5444 packet. I just checked.
>>>>>> 
>>>>>> This makes this posting of yours even more of a waste of time than usual.
>>>>>> Will you please actually read and understand things before commenting.
>>>>>> (Putting aside the timescale issue.)
>>>>>> 
>>>>>> (The protocol thus does exactly what it needs to do with regard to the
>>>>>> 5444 multiplexer. Nothing.)
>>>>>> 
>>>>>> 
>>>>>>> On 12 Sep 2014, at 03:34, Abdussalam Baryun wrote:
>>>>>>> 
>>>>>>> In another discussion the WG may want RFC5444 packets not mentioned in
>>>>>>> our protocols because it belongs only for multiplexer. However, This draft
>>>>>>> mentions packets and many protocol considerations for RFC5444 packets. The
>>>>>>> draft avoid even mentioning the multiplexer, even though it is very
>>>>>>> important for the use case.
>>>>>>> 
>>>>>>> Therefore, either take out all describing packets in draft (put it in
>>>>>>> one place as the management consideration section), which I don't think is
>>>>>>> correct because it's an MT protocol, or specify a protocol for multiplexer
>>>>>>> in another draft, or do specify multiplexing in this draft. There is an
>>>>>>> assumption in the draft which I don't think can be accepted to avoid
>>>>>>> multiplexing while considering packets and MT.
>>>>>>> 
>>>>>>> IMHO the draft needs to specify how the multiplexer packs its MT
>>>>>>> messages so that each packet go through the right topology. Specifying
>>>>>>> parser/multiplexer function is because this draft is mentioning packets and
>>>>>>> messages for MT without mentioning multiplexer. We should ensure that each
>>>>>>> packet routes in one topology and messages are packed correctly. For example
>>>>>>> I don't find the function maintaining that messages of one topology are not
>>>>>>> mixed with messages of other topologies.
>>>>>>> 
>>>>>>> AB
>>>>>>> _______________________________________________
>>>>>>> manet mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>> 
>>>>> _______________________________________________
>>>>> manet mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>>