Re: Two week Last Call on LMP

[Jonathan Sadler <jonathan.sadler@tellabs.com>]

Hello Jonathan, et al. 

Some comments on draft-ietf-ccamp-lmp-02.txt:

1. (Sec 14.13) The definition of the Interface Switching Capability
subobject within the Data Link Object seems inconsistant with the
definition that exists within the routing drafts where the
interpretation of minimum/maximum bandwidth range is different for each
swithing type.

The current definition also states:

"If more than one subobject of the same Type appears, only the first
subobject of that Type is meaningful.  Subsequent subobjects of the same
Type MAY be ignored."

This is problematic regardless of how you interpret the minimum/maximum
bandwidth range as it doesn't allow for multiple subobjects.  Multiple
subobjects will be needed for devices that don't support all signals for
the minimum/maximum bandwidth range given for a particular switching
capability, and encoding type.  This support would be needed for a
device that supported standard SONET VT1.5, VT2, STS-1, STS-3c, STS-12c,
and STS-48c switching, but couldn't switch VT6.

2. (Sec. 13.6.6) The Test message only includes VERIFY_ID and
LOCAL_INTERFACE_ID.  Since this message could be extended to support
automatic "discovery" of neighbors, why not also include a "control
plane contact address"?

3. (Sec. 14.9) No details are given regarding the encoding of the test
message for DCCS or DCCL.  I assume that if PPP is used, it will be
conformant to appropriate IETF standards (ie. RFC 1661).

Jonathan Sadler