[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-ietf-ccamp-gmpls-addressing-02.txt
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)
" 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)
" 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 ?
is this section really dealing with usage of addressing in GMPLS nets ?
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