Subject: RE: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 20 Apr 2007 14:02:32 +0000

Hi Robert

Here are some comments on v.13 of the GIST draft.

In general, I agree with the information provided in this version of the
GIST draft, however, I have some comments:

------------------------------
Comment_1:
Section 4.3.3, second bulet from top on page 31, regarding message size
specification:

This bullet is very unclear. Could you please clarify this point by e.g.,
providing a description in a pseudo code like form?

-----------------

Comment_2:
Section  4.3.3, in the discussion of the situation that a message
association is not required and the message is sent in D-mode, I mis the
situation, which describes that if a routing state exists and the NSLP
requires via the Local Policy (Message Transfer Attribute) to not use
this routing state and if the MRI can be used to derive the Q-mode
encapsulation then a GIST DATA or GIST QUERY message can be sent using
the Q-mode encapsulation.

Please change the last bullet on page 31:
FROM:
" * If the message is not a QUERY, and routing state exists, it is sent
with normal D-mode encapsulation directly to the address from the
routing state table."

INTO:
" * If the message is not a QUERY or DATA, and routing state exists, it
is sent with normal D-mode encapsulation directly to the address from
the routing state table.

* If the message is a DATA, and routing state exists, and if the NSLP
requires via the Local Policy (Message Transfer Attribute) to not use
this routing state, and to use the MRI to derive the Q-mode
encapsulation information, then this message can be sent using the
Q-mode encapsulation."

-------------------------------------

Comment_3:
This comment is similr to Comment_2, but it relates to Section 5.3.2,
page 54:

Please change the text
FROM:

"Q-mode encapsulation MUST be used for messages where no routing state
is available or where the routing state is being refreshed, in
particular Query messages."

INTO:

"Q-mode encapsulation MUST be used for messages where no routing state
is available or where the routing state is available, but it is either
being refreshed or the NSLP requires via the Local Policy (Message
Transfer Attribute) to not use this routing state, and to use the MRI to
derive the required Q-mode encapsulation information."

----------------------------------------

Comment_4:
This comment is similar to Comment_2, but it relates to Section 5.5, see
table on page 60:

Please change the third column of the table on the row associated with
the DATA message:

FROM:
"If no routing state exists and the MRI can be used to derive the Q-mode
encapsulation"

INTO:
"If no routing state exists and the MRI can be used to derive the Q-mode
encapsulation.
If routing state exists and the NSLP requires via the Local Policy
(Message Transfer Attribute) to not use this routing state, and the MRI
can be used to derive the Q-mode encapsulation."

---------------------------
Comment_5
Section 5.3.3, page 58:

I would like to be emphasized that if the rules given in 4.3.3 are
satisfied then the D-mode can also be used for normal signaling traffic.
Please add the following sentence at the bottom of page 58:

"However, when the rules given in Section 4.3.3 are satisfied then the
D-mode MAY also be used for normal signaling traffic."

--------------------------------------

Comment_6
The explanation and the motivation of using the magic number should be
described in the first sections of the draft.

----------

Comment_7:

Section 5.3.2.3, page 56, editorial:
Please change:
FROM:
"within the networ which"

INTO:
"within the network which"

-------------------------------

Comment_8
Section 5.5, page 60, editorial:
Please change:

FROM:
"except that that the"

INTO:
"except that the"

Best regards,
Georgios

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Lars Eggert <[email-masked]>
Date: Tue, 24 Apr 2007 16:15:23 +0300

> providing a description in a pseudo code like form?

This reminds me that I forgot to send in a comment that the following  
text about message sizes is wrong:

       The message size MUST NOT exceed the
       least of the following three quantities: the Path MTU to the next
       peer (if known), the first-hop MTU, and 576 bytes.  The same  
limit
       applies to IPv4 and IPv6.

This text never lets you send anything over 576 bytes, because min 
(pmtud-to-next-peer, first-hop-mtu, 576) <= 576 bytes

You probably want something similar to this text:

    The message size MUST NOT exceed the path MTU to the next peer. If
    that is unknown, the message size MUST NOT exceed the lesser of
    576 bytes and the first-hop MTU. The same limit applies to IPv4
    and IPv6.

Lars

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 24 Apr 2007 14:17:09 +0100

yep.

(this is the same conclusion georgios and I came to offline, fortunately.)

r. 

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: 24 April 2007 14:15
> To: ext Georgios Karagiannis
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt
> 
> > This bullet is very unclear. Could you please clarify this point by 
> > e.g., providing a description in a pseudo code like form?
> 
> This reminds me that I forgot to send in a comment that the 
> following text about message sizes is wrong:
> 
>        peer (if known), the first-hop MTU, and 576 bytes.  
> The same limit
> This text never lets you send anything over 576 bytes, 
> because min (pmtud-to-next-peer, first-hop-mtu, 576) <= 576 bytes
>

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 25 Apr 2007 10:30:08 +0100

On a related point, section 4.3.4 (page 33) says:
 >  1.  The message is so large that it would be fragmented on downstream
 >      links, for example because the downstream MTU is abnormally small
 >      (less than 512 bytes).  The error "Message Too Large"
 >      (Appendix A.4.4.8) SHOULD be returned to the sender, which SHOULD
 >      begin messaging association setup.

I'm not clear why a value of 512 bytes is used here, rather than the 576 
bytes given in 4.3.3.

Possibly 512 bytes is meant to be the GIST data size (i.e. GIST message 
excluding IP/transport headers), since that would make a message size of 
576 bytes with the 64 byte header allowance given in 4.3.3.

Andrew

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 25 Apr 2007 11:36:01 +0200

Hi Andrew

I agree with your observation!

Best regards,
Georgios 

> From: Andrew McDonald [mailto:[email-masked]] 
> Sent: woensdag 25 april 2007 11:30
> To: Robert Hancock
> Cc: 'Lars Eggert'; 'ext Georgios Karagiannis'; [email-masked]
> I'm not clear why a value of 512 bytes is used here, rather 
> than the 576 bytes given in 4.3.3.
> 
> Possibly 512 bytes is meant to be the GIST data size (i.e. 
> GIST message excluding IP/transport headers), since that 
> would make a message size of
> >>> Section 4.3.3, second bulet from top on page 31, 
> regarding message 
> >>> size
> >>> specification:
> >>>
> >>        least of the following three quantities: the Path 
> MTU to the 
> >> next