The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

Josh> I think this  is the case when two frame-based  LSRs are connected via
Josh> an ATM VP through an ATM cloud. 

I've never heard of such a  configuration.  A VP is generally a path between
two ATM switches, not between two ATM endnodes.

Josh> However, your answer makes me think that I may be missing something in
Josh> the big  picture of how MPLS  will be deployed, and  what the networks
Josh> will look like.  Here is what  I conclude about this picture from your
Josh> answer:

Josh> 1) In an ATM-LSR  domain, frame-based LSRs are only  found in the edge
Josh>    set of the domain

Yes, true by definition.

Josh> and  will  only  be   connected  via  ATM-LSRs  (and  never  connected
Josh> directly). 

No, not  necessarily.  But if  two frame-based LSRs are  directly connected,
there is no reason to use an LC-ATM interface to connect them.

Josh> 2) The problem of  penultimate hop pop in this  environment (which was
Josh>    my  original preoccupation)  is  a non-issue.   ATM-LSRs can't  pop
Josh>    labels from the Josh> stack, so the label depth will only change at
Josh>    the ultimate hop, i.e. at the edge. 

Right.

Josh> Do  you  believe that  this  is impossible  because  R23  would be  an
Josh> ATM-LSR, incapable of  popping the label stack? Or  is this because if
Josh> R3 distributes  an implicit null  to R23, R23  would have no  value to
Josh> place in the VP/VC field in order to forward the packet to R3? 

Nothing  so deep.  On  an LC-ATM  interface, R3  would only  specify VPI/VCI
values  as the  label, and  we haven't  reserved any  VPI/VCI value  to mean
"implicit null".