Subject: RE: GMPS Unnumbered

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 21 Sep 2001 09:46:55 -0400

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)

   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.
  Thanks!

--Venkata Naidu

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 23 Sep 2001 07:28:31 -0700

Venkata,

>    (hope you won't suggest link bundling here)

what would be the problem(s) with using link bundling in this case ?

>      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).
  
>      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 ?

>      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.

>      and which are mandatory. And any restriction about processing

This draft just follows the approach of the "basic" MPLS TE routing
extensions.

Yakov.