[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-05.txt {3}

catching up with old email...

El 30/11/2006, a las 20:34, Deguang Le escribió:


Hi Marcelo,
I am sorry for my late response.
Thanky you very much!
See my comments inline... :-)

marcelo bagnulo braun schrieb:


Hi Deguang,
El 15/10/2006, a las 15:24, Deguang Le escribió:

Hi all,
a slight comment on the Context Tag...

-Page50
   o  The context tag used to transmit control messages and payload
      extension headers - allocated by the peer; CT(peer)
-Page51
   o  The context to expect in received control messages and payload
      extension headers - allocated by the local host; CT(local)
In page 50 and 51, two parameters, namely CT(peer) and CT(local), are defined for each ULID-pair context. right? 

However, in page 13, the terminology of CT is given as follows:
Context tag Each end of the context allocates a context tag 
                       for the context.  This is used to uniquely
                       associate both received control packets and
                       payload extension headers as belonging to the
                       context.
Based on my understanding of above CT terminology, for a given context, there is only "A" unique context tag used to identify the context (i.e. the ULID-pair context, right?).
no, the above terminology states that _each_ end of the context allocates one context tag. since there are two ends in a shim context, this sums two context tags, right? CT(peer) and CT(local) 
You are right.
Thank you very much! I think I understand what the two CTs means and
their usages now.
You mean each established shim6 context is identified by two CTs (i.e. a 
peer CT and a local CT) in fact, and the values of these two CTs are
different. Right? :-)

However, I wonder why two endpoints can not negotiate "a" CT to
establish and identify a shim6 context. Is it not feasible to establish
a shim6 context if only "one" CT is used for identifying a context?
it would be possible of course, but i think it will be more difficult....
one option would be create the CT as the concatenation of both CTs, sso it would be easy to guarantee the uniquenes, but the price is that the CT lenght is the double, right?
the other option is to negotiate a CT, making one end to propose a CT and the other end verifying that it is good for him. In this case the additional cost comees from the negotiation phase.
So, in brief, it is possible to have a single CT but is has an additional cost, either on CT length or in negotiation steps, but the question is what do you want this for? what does this provides? 

regards, marcelo



Cheers,
Deguang




Regards, marcelo
Therfore, I am confused why each ULID-pair context needs these "TWO" context tags: CT(peer) and CT(local)? Are the CT(peer) and the CT(local) the same thing (or are they the same 47-bit number?)in essence? 


Have a nice weekend!
Cheers,
Deguang