Joel M. Halpern | 1 Apr 03:04 2008

Re: Protocol Draft - KEYINFO-TLV

The KeyData is, I believe a FULLDATA TLV, as it can be any form of data, 
and may need its own length.

The KeyID is an ID, as defined in the model.  There can be multiple 
keys, each made up of multiple values.  The keyid tells you wha tkey is 
being used.  Please look at the model and let us know if there is a need 
for more text on that.

Yours,
Joel M. Halpern

Evangelos Haleplidis wrote:
> Greetings again to the list,
> 
> I have some comment regarding the KEYINFO-TLV.
> 
> 1. As with the PathData TLV there was no Graph, so I made up one. I include
> it in the end of the mail.
> 2. About the KeyID, it is not specified specific in the document what the
> size is. I guess it is an integer, shouldn't it be specified for clarity?
> How many Keys may exist for a specific table? Could/Should the KeyID be
> limited to less than 4 bytes?
> 3. In Page 45 it is written:
>        KEYINFO-TLV := KeyID FULLDATA-TLV
> Shouldn't it be changed to:
>        KEYINFO-TLV := KeyID KEYDATA
>        KEYDATA := FULLDATA-TLV
> Or
>        KEYINFO-TLV := KeyID KeyData
> This would be in accordance with the examples also in the appendix.
(Continue reading)

Evangelos Haleplidis | 1 Apr 14:57 2008
Picon

Protocol Draft - KEYINFO-TLV

Greetings,

My question was what the size of the KeyID, in terms of the protocol
message, is. Are the KeyIDs 4 bytes long? I couldn't find any specification
in the protocol draft, and I believe there should be one in there, or an
explanation of how to get it. Or is it derived by the KeyInfoTLV's L value?
I couldn't find a text that explains that also. 

Also, how many keys can there be in an array? Will there be more than 127
(1byte)? Is there a need for 4 bytes? Since for each array we can have
individual numbering.

Regards,
Evangelos Haleplidis.

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern
Sent: Tuesday, April 01, 2008 4:05 AM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: Protocol Draft - KEYINFO-TLV

The KeyData is, I believe a FULLDATA TLV, as it can be any form of data, and
may need its own length.

The KeyID is an ID, as defined in the model.  There can be multiple keys,
each made up of multiple values.  The keyid tells you wha tkey is being
used.  Please look at the model and let us know if there is a need for more
text on that.

(Continue reading)

Wang,Weiming | 1 Apr 17:03 2008
Picon

Re: Protocol Draft - KEYINFO-TLV

Hi Evangelos,

From the contecptual point of view,  the KeyID is a type of  "IDs" as explained in p.45, which occupying the
same length (32bits). Whereas, I agree that applying a text like KeyID(32bits)  in the KeyID term
explanation paragraph might make things more clear. 

On the graph description of the Path-Data-TLV, I just think current BNF is a clear and efficient method. At
the time we chose the BNF, we had made some considerations like the inefficiency for graph to describe
duplicate TLVs case and the self-contained TLV case. 

Thanks a lot for the careful review.

Thanks,
Weiming

----- Original Message ----- 
From: "Evangelos Haleplidis" <ehalep <at> gmail.com>

> Greetings,
> 
> My question was what the size of the KeyID, in terms of the protocol
> message, is. Are the KeyIDs 4 bytes long? I couldn't find any specification
> in the protocol draft, and I believe there should be one in there, or an
> explanation of how to get it. Or is it derived by the KeyInfoTLV's L value?
> I couldn't find a text that explains that also. 
> 
> Also, how many keys can there be in an array? Will there be more than 127
> (1byte)? Is there a need for 4 bytes? Since for each array we can have
> individual numbering.
> 
(Continue reading)

Jamal Hadi Salim | 1 Apr 21:48 2008

Re: Protocol Draft - PathDataTLV

Greetings Evangelos,

Much thanks for the review; comments below.

On Mon, 2008-31-03 at 22:56 +0300, Evangelos Haleplidis wrote:

[..]

> 1. Path-Data-TLV is the only TLV (besides KEYINFO-TLV) that is not depicted
> as a graph in the document. While it is described, it would be good for
> consistency to be seen. In the end of the document I include an example.

Looks usable to me. If there are no objections from the other authors,
we should include it.

> 2. In the second text the part "when PATH flags are 00" should be changed to
> "when PATH flags are 0x00", unless there was intended as 0b00. It should be
> specified however for clarity.

I think that paragraph is a bit confusing; please refer to the other
text I am suggesting below to replace that section.

> 3. About Selector Bit, in which position does it exist in the flags? I guess
> it should be the first. However I think it should be documented for clarity
> purposes (I also include a graph in the end of the mail).
> 

Hrm. Good catch. Our implementation has it at the other end. i.e. bit 15
May i suggest we put it there?

(Continue reading)

Evangelos Haleplidis | 1 Apr 23:20 2008
Picon

Re: Protocol Draft - KEYINFO-TLV

Greetings again to the list,

I have a new question regarding the KeyInfoTLV.

Page 45:
       KEYINFO-TLV := KeyID FULLDATA-TLV

Page 46 About KeyData.
      *  The key's data is the data to look for in the array, in the
         fields identified by the key field.  The information is encoded
         according to the rules for the contents of a FULLDATA-TLV, and
         represent the field or fields which make up the key identified
         by the KeyID.

If I understand this correctly then the KeyInfoTLV should look like this:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = KeyInfo         |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             KeyID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = FullData        |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Value=KeyData                         |
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If this is the case, then does the KeyInfo Length contains also the length
(Continue reading)

Evangelos Haleplidis | 1 Apr 23:33 2008
Picon

Re: Protocol Draft - PathDataTLV

Greetings,

Thanks for the answers.

The new text is indeed more clear.

Regards,
Evangelos Haleplidis 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Tuesday, April 01, 2008 10:48 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: Protocol Draft - PathDataTLV

Greetings Evangelos,

Much thanks for the review; comments below.

On Mon, 2008-31-03 at 22:56 +0300, Evangelos Haleplidis wrote:

[..]

> 1. Path-Data-TLV is the only TLV (besides KEYINFO-TLV) that is not
depicted
> as a graph in the document. While it is described, it would be good for
> consistency to be seen. In the end of the document I include an example.

Looks usable to me. If there are no objections from the other authors,
(Continue reading)

Avri Doria | 2 Apr 15:47 2008

Re: Protocol Draft - PathDataTLV

Hi,

as long as it is ok with the group and the shepherd, I will save up  
all the changes for a post IETF LC release.

thanks

a.

On 1 Apr 2008, at 21:48, Jamal Hadi Salim wrote:
> Greetings Evangelos,
>
> Much thanks for the review; comments below.
>
> On Mon, 2008-31-03 at 22:56 +0300, Evangelos Haleplidis wrote:
>
> [..]
>
>> 1. Path-Data-TLV is the only TLV (besides KEYINFO-TLV) that is not  
>> depicted
>> as a graph in the document. While it is described, it would be good  
>> for
>> consistency to be seen. In the end of the document I include an  
>> example.
>
> Looks usable to me. If there are no objections from the other authors,
> we should include it.
>
>> 2. In the second text the part "when PATH flags are 00" should be  
>> changed to
(Continue reading)

Patrick Droz | 4 Apr 11:49 2008
Picon

[Fwd: Change in Forces WG co-chair]

I am forwarding this not on behalf of Ross. I am also welcoming Jamal on 
board!

Regards,
Patrick

-------- Original Message --------
Subject: 	Change in Forces WG co-chair
Date: 	Thu, 3 Apr 2008 12:59:12 -0400
From: 	Ross Callon <rcallon <at> juniper.net>
To: 	<forces <at> peach.ease.lsoft.com>
CC: 	Ross Callon <rcallon <at> juniper.net>, David Ward <dward <at> cisco.com>,
<David.Putzolu <at> intel.com>, <dro <at> zurich.ibm.com>, <hadi <at> znyx.com>

Dave Putzolu has asked to step down as Forces working group co-chair.
Dave has become busy with other work recently, and therefore no longer
has time to serve as co-chair. I would like to thank Dave for multiple
years of service as co-chair (preceding my time as Routing AD).

Jamal Hadi Salim has agreed to take over as co-chair. I am sure that 
Jamal will be familiar to most Forces participants due to his being very
active in the group. I would like to thank Jamal for being willing to 
step up as co-chair.

The working group charter page will be updated to reflect these changes
in the near future.

Thanks, Ross

--

-- 
(Continue reading)

Patrick Droz | 4 Apr 12:00 2008
Picon

Re: Protocol Draft - PathDataTLV

Hi Avri,

yes, this is fine with me.

Regards,
Patrick

Avri Doria wrote:
> Hi,
> 
> as long as it is ok with the group and the shepherd, I will save up all 
> the changes for a post IETF LC release.
> 
> thanks
> 
> a.
> 
> 
> 
> On 1 Apr 2008, at 21:48, Jamal Hadi Salim wrote:
>> Greetings Evangelos,
>>
>> Much thanks for the review; comments below.
>>
>> On Mon, 2008-31-03 at 22:56 +0300, Evangelos Haleplidis wrote:
>>
>> [..]
>>
>>> 1. Path-Data-TLV is the only TLV (besides KEYINFO-TLV) that is not 
>>> depicted
(Continue reading)


Gmane