[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP revision 04
Bert,
Thanks for the thorough review and constructive comments. I have spoken
with the LMP Security authors and they have agreed to merge that document
into the LMP document. We will address this and your other comments in the
next version.
Thanks,
Jonathan
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Wednesday, August 07, 2002 1:15 PM
> To: Ccamp-wg (E-mail)
> Subject: LMP revision 04
>
>
> I have reviewed this document with my AD hat on.
>
> Here are my comments/question
>
> - My biggest question is:
>
> How does this fit in CCAMP in terms of providing a
> COMMON control protocol and/or COMMON measurement protocol.
>
> Remember our architecure, which is as follows:
>
> --- pictorial overview of work in the sup-IP area --------------
>
> The Working Groups at the top are those that will use the
> Common Control and Measurement Protocols that we're
> defining in the CCAMP WG.
>
>
> Applications +-------+ +-------+ (new) Hour glass
> that use CCAMP: \ | TE-WG | | PPVPN | ... /
> \ +-------+ +-------+ /
> \ +----------------------+ /
> \ | CCAMP | /
> \ |-----------+----------| /
> / | C | M --|------ IGP LSA ext
> / | control | measure | \
> / +----------------------+ \
> Technologies to / +----+ +----+ +----+ +----+ +----+ \
> measure/control:/ |MPLS| |OPT | |RPR | |ATM | | FR |...\
> +----+ +----+ +----+ +----+ +----+
>
> The technologies at the bottom allow us to create paths and so those
> are the ones we want to measure and control via the Common Control
> and Measurement Protocols coming out of CCAMP. One of those
> technologies (MPLS) is defined by IETF, others are (have
> been) defined
> in other standards organisations. However, we want to focus
> mainly on
> the use of such technologies for IP.
>
> So for example the IPO and IPORPR WGs are assumed to be active at
> the bottom because we want to focus on the IP use of such
> technologies.
>
> Anyway, further with more detailed comments
>
> - add a note that RFC-Editor can remove the "changes
> from previous section" when publishing as RFC
>
> - I am not an expert in the optical world. So I can identify
> with questions about terminology as we have seen lately.
> It probably would be good to add a section at the beginning
> that lists the terms uses and what is meant by them in this
> document. I mean terms like: port, component link,
> control channel, multiplex cpability, TE link, bundle,
> data link, data-bearing link, link property correlation,
> opaque mode, transparent mode,
> etc.
>
> - I see terms like "data-link", "data-bearing-link" etc.
> Are these basically the same? If so, can we try to be consistent
>
> - You are using MUST/SHOUL/etc language, and so you better explain
> at the beginning how these terms are used. probably in the sense
> of RFC2119, and if so, then a reference to that RFC is needed
> as well.
>
> - I see the use of CC-ID, CCId, maybe other notations.
> I think they are all the same. If so, be consistent pls
>
> - I am confused. It states several times that LMP runs over UDP
> and then states at various other places that the LMP
> messages are IP encoded, which sort of sounds as if it runs
> on rraw IP.
>
> - At several places you write "this draft". I think better is
> "this document" so that it also applies when it becomes an RFC
>
> - Sect 3.2
> Is the LMP "channel" used for just LMP or also for other
> purposes. It seems the latter cause you talk about not
> loosing IGP hellos in this section. I think you should
> then make it clear at some place what kind of traffic
> goes over the "LMP channe". Or is it only that you believe
> that as long as the two end-points (IP addresses) of the
> LMP "channel" can exchange LMP Hellos, that you assume that
> other IP based protocol messages will also reach the
> other side?
>
> - Last sentence in first para of sect 3.2.2.
> It says:
>
> The sequence numbers start at 1 and wrap
> around back to 2; 0 is used in the RcvSeqNum to
> indicate that a Hello has not yet been seen.
>
> I have a hard tim eunderstanding what it says.
>
> - bottom of page 10 (but also at other places) I see
>
> If ((int) old_id û (int) new_id > 0) {
> New value is less than old value;
> }
>
> what does that U accent-grave (or u with a carrot) mean?
>
> - you use terms like capital DOWN and UP, sometimes it is
> Up, sometimes just lowercase.... Migth want to be consistent
> In fact I am not sure why you need to capitalize at all.
>
> - Last sentence of sect 4 ???
> If you send data in UDP packets, then IP fragmentation
> happens automagically at the IP layer if needed. That is
> if the system supports it (I am hearing more and more that
> such is not always the case).
>
> - Section 5 tells me that Test Messages go over the "data links"
> which is then further detailed in section 14.8
> Is this a layering violation?
> Is this IETF territory or Optical Plane territory?
>
> - Sect 6.3 near the top of page 19 has a sentence starting:
> When Node 3 correlates the failure and verifies that it is
> CLEAR,
> What does that capitalized CLEAR mean? Special meaning?
> From some other spec ?
>
> - Sect 7 towards the bottom speaks of messages that can be
> out of order. I suspect that such messages should be dropped?
> But such is not clear from the text.
>
> - sect 8 talks about a "control plane restart".
> What does that mean?
> And what is an "LMP componentn restart" ??
>
> - sect 9 (among others) states that LMP messages are sent directly
> over IP, seems to be conflicting with earlier claims that it
> is sent over UDP.
>
> - sect 10 first sentence talks about "back procedures" ??
>
> - Sect 11 is the IANA COnsiderations.
> I think it is far from complete.
> - you want/need a port number I think
> - you are making lots of assignments late in this
> document. I guess you want IANA to start that name
> space and assign the initial values you specify in this doc
>
> - Sect 13 again claims that msgs are IP encoded
>
> - Sect 13.1 claims there is the standard IP hdr and then the LMP
> common header. I expect there is also the UDP header.
>
> - I expect that when you have fields that are 16 bits long
> (like LMP length, Checksum) that those are in network
> byte order. Might be good to state so.
>
> - Do you need a checksum if you send over UDP?
> Anuway, you claim it is "the standard IP checksum".
> Not sure that is true. ANd you might want to specify how
> the fields like the checksum itself needs to be initialized
> (zero I guess) when the checksum is calculated?
>
> - I would make a note that "reserved field" be sent as zero
> and be ignored on receipt
>
> - Sect 13.5.6.
> So the Test Message is not send as a UDP packet?
> Instead it is send as a raw IP packet?
> And then in sect 14.8 you even claim taht for J0-16 it is NOT
> send as an IP packet and then for the others it is sent as
> IP packet.
>
> Yuck yuck yuck...
>
> - I see that you make some values "reserved for OIF".
> That does not seem to belong in a protocol standards track
> document. If OIF needs assigments, then can request such
> assignments from IANA once thsi doc gets approved and
> according to the guidelines that this WG provides to IANA.
>
> - I think on page 61, C-Type=2 is an IPv6 Interface ID
> and not an IPv4 Interface ID
>
>
> - Setc 14.15
> A value of 0x01 in a 32bit field. I guess it is network
> byte order and the value is 0x00000001
> Not sure if that is clear to everyone
>
> - The security considerations being discussed in a separate
> document is really strange. Pls merge them into this doc.
>
>
>
> Thanks,
> Bert
>