The MPLS WG Archive

["James R. Leu" <jleu@laurelnetworks.com>]

Hello,

While reading draft-ietf-mpls-lmp-00.txt, I noticed a couple of
areas which could use some editing or clarification.

Section 9.4.5 "EndVerifyAck Message"
------------------------------------
The phrase "The EndVerifyNack object has the following format:"
Should be "The EndVerifyAck object has the following format:"

Section 9.1 "Common Header"
---------------------------
Isn't it common practice to byte align fields?  If so I suggest:
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Vers  |   (Reserved)         |     Flags      |    Msg Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                      Control Channel Id                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Section 9.4.6 "Test Message"
----------------------------
Correct me if I'm wrong, but isn't the Link Id value which is being
exchanged used in draft-kompella-mpls-bundle-03.txt section 5.2.1 
"COMPONENT_INTERFACE_ID Object Class" where it is specified as a 16 bit
number?

(the same statement holds true every place where Link Id is specified)

Section 9.5.1 "LinkSummary Message"
-----------------------------------
If my understanding is correct, a Link Summary message could contain a
sub object for every working channel between the two nodes.  If this is correct
isn't there a concern that the resulting PDU will exceed the MTU or 
available receive buffers on a node?  Maybe a Maximum Protocol PDU size should
be negotiated during the configuration state.

General
-------
I know this is being very "nit-picky", but you will need a section addressing
the implications of using IPv6 addresses before this can move move towards
RFC state.

Jim
-- 
James R. Leu
Software Engineer
Laurel Networks, Inc
jleu@laurelnetworks.com