comments on draft-ietf-ccamp-gmpls-addressing-02.txt

[dimitri papadimitriou <dpapadimitriou@psg.com>]

hi - some comment on this document after first reading (note: text has 
improved since last version but some shaded sub-sections remain and i 
still find some sentences with ambiguous/dual interpretation but this 
would be normally to be tackled during the editorial review)

Section 7.1.1

"  4. Outgoing TE link ID optionally followed by Component Interface ID
      subobject and/or one or two Label subobjects "

applies for so called egress control so there no such "optional"
follow-up object; these are present by definition - see also RFC 4003 
that clarifies the procedures for the control of the label used on an 
output/downstream interface of the egress node of an LSP

"  There is no way to specify in the ERO whether a subobject is
   associated with the incoming or outgoing TE link.  This is
   unfortunate because the address specified in a loose subobject is
   used as a target for the path computation, and there is a big
   difference for the path selection process whether the intention is to
   reach the target node over the specified link (the case of incoming
   TE link) or to reach the node over some other link, so that it would
   be possible to continue the path to its final destination over the
   specified link (the case of outgoing TE link).

   In the case where a subobject in an ERO is marked as a loose hop and
   identifies an interface, the subobject SHOULD include the address of
   the Incoming interface specifying the TE link in the data plane. "

but by definition the latter applies (it is not a "SHOULD" its de-facto)
so why is this indication needed ? - see RFC3209 section 4.3.4

+ would you drop a line on ERO processing at region boundaries per 
LSP-HIER (Section 8.2)

Section 8.2

"   If the control plane interface is unnumbered, the RECOMMENDED value
   for the control plane address is the TE Router-ID. "

what does "control plane interface is unnumbered" means ? btw i thought
IP source/dest. address settings were discussed in section 5. - why
re-discuss this here ?

Section 9

is this section  really dealing with usage of addressing in GMPLS nets ?

Section 10

   For this feature to be used, all LSRs in the network MUST advertise a
   32-bit value that can be used to identify the LSR.  In this document,
   this is referred to as the 32-bit LSR ID.  The 32-bit LSR ID is the
   OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784].
   Note that these are different from TE router ID (See Section 3).

=> in section 10 a new definition falls 'LSR ID'; i found the text
confusing; it is different from the TE Router ID but it is named the TE 
Router ID; it is the Router ID of OSPFv3 and not sure it is the Traffic
Engineering router ID TLV is TLV type 134 of IS-IS - last sentence seems
to say the contrary