[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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