Re: GMPS Unnumbered

[Yakov Rekhter <[e-mail]>]

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.