[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPS Unnumbered
-> > * MPLS-TE extensions define Interface IP Address TLVs
-> > (Type 3 and 4) as length of 4N. Where N is the number of
-> > local IP addresses for that Interface.
-> > But in GMPLS, why can't we configure multiple "unique"
-> > Interface IDs for Unnumbered interfaces? Please allow
-> > flexibility with out restricting one ID for Unnumbered Link.
-> What kind of problem(s) would that solve ?
If for example, a physical p2p link is sub divided into
multiple "logical" links (such as ATM VP/VC) each has
identifiers but represents same other characteristics
(like bw etc) then there is no point in generating multiple
link TLVs for each of those "logical" interfaces. Considering
OSPF is implemented as per draft-ietf-ospf-ppp-flood-01.txt.
(hope you won't suggest link bundling here)
Please see more comments on GMPLS Routing below:
* There is no mention about Interface MTU in
draft-ietf-ccamp-gmpls-routing-00.txt, but I can see the
use in draft-ietf-ccamp-ospf-gmpls-extensions-00.txt
(as Sub TLV type 10).
More over, "logical TE link" (with no OSPF adjacency) need not
signify "Interface MTU" but "path MTU" suites well(?)
* I suggest/request to include "delay" also in GMPLS enhancements.
None of the TE extensions (MPLS, DiffServ, GMPLS) considered
"link delay" as one of path computation constraint. (could be
NP-complete but there are means to compute path and very helpful
in Traffic Management/QoS cases for delay sensitive applications)
* Is that Sub-TLV types 3|4 and 11|12 are mutually exclusive?
If not what would be the behavior if OSPF receives all of
above TLVs. (is there any possibility here that we can save
some types/overhead with regards to scalability)
* Minor: there is no mention about which Sub-TLVs are optional
and which are mandatory. And any restriction about processing
the (un)recognized TLVs?
I have few more comments with regards to Link Protection and SRLG.