[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GMPS Unnumbered
Venkata,
> Yakov:
>
> -> > * 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)
what would be the problem(s) with using link bundling in this case ?
> 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 actually wonder whether it would make more sense to carry MTU
not as a Sub-TLV, but in the Switching Capability specific information
(for PSC links only). (For one thing, I don't think MTU has any
meaning on non-PSC links).
> * 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)
Did you have a chance to look at the proposal suggested in
draft-lefaucheur-te-metric-igp-00.txt ?
> * 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)
I guess in principle the same link could be both numbered and
unnumbered (why would one do this in practice is a completely
different question). So, at least in principle one could argue that
3|4 and 11|12 may not be mutually exclusive.
>
> * Minor: there is no mention about which Sub-TLVs are optional
> and which are mandatory. And any restriction about processing
> the (un)recognized TLVs?
This draft just follows the approach of the "basic" MPLS TE routing
extensions.
Yakov.