[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working Group Last Call on draft-ietf-ccamp-gmpls-addressing-06.txt
Good comments. Thanks.
In the abstract and the introduction, the phrase "facilitate
better interworking" reads weird to me. I'm not a native
English speaker, but wouldn't "facilitate interworking" be
About the IGP terminology, in OSPF and IS-IS RFCs,
"OSPF-TE" and "IS-IS-TE" terms are reserved for
MPLS-TE extensions (RFC 3630 and 3784) while
GMPLS ones (RFC 4203 and 4205) are rather named
"GMPLS OSPF" and "GMPLS IS-IS". I believe the ID
should follow this terminology more closely.
In section 5.1.1:
"An unnumbered TE
link end network-wide identifier is comprised of a TE Router ID
associated with the link local end, followed by the link local
The intent on (TE Router ID, link local ID) is clear to anyone
familiar with the context, but I also feel -- due to my mother
tongue? -- that this might also be misread as (TE Router ID,
link local end, link local ID), which does not make any sense.
However, considering this is a clarification document, maybe
replacing "associated with" by "corresponding to" or just
recalling it's a pair would do the trick.
An unnumbered TE link end network-wide identifier is comprised
of two elements:
- a TE Router ID that is associated with the link local end
- the link local identifier.
In section 6.1.2:
"If the interface was intended to be used as an outgoing
interface, the path will be broken an may be impossible to
"The path will be broken" looks like a postulate and needs a
Yes, the sentence and the path are broken :-)
If the interface was intended to be used as an outgoing
interface, the computed path may be unsatisfactory and
the explicit route in the ERO may be impossible to resolve.
"This a loose hop that identifies an interface should always
identify the incoming TE link in the data plane."
Something's missing or "This" should be removed.