The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Last call comments
Eric I personally find the uniform model more useful than the pipe model. For a transit backbone carrier, uniform model may make more sense than the pipe model. The pipe model makes more sense VPNs, OXCs, etc. Bora Eric Gray wrote: > Shahram, > > Thanks for the clarification on use of DE/CLP. > > Could you please move the paragraph that says > "the Uniform Model allows LSPs to span Diff-Serv domain > boundaries" (toward the bottom of page 12) to a spot > closer to the point at which this model is defined (e.g. > - 2.6.3). This paragraph makes some things much clearer. > > Let me see if I understand now. > > The reason why the penultimate hop needs to perform the > EXP'->EXP conversion is because the next hop LSR cannot > tell the difference between PHP'd packets and non-PHP'd > packets therefore all packets have to arrive with correct > EXP (or DSCP) value for the applicable LSP stacking level. > > Is this correct? > > I seem to recall that there is not a lot of current > interest in LSPs that span service boundaries. So is it > fair to say that there may not be a need to support the > Uniform model in the very near future? Yet the Uniform > model is specified as the 'base mandatory mode'. The Pipe > model is clearly simpler to support with or without PHP > and the biggest operational difference is that it requires > LSP tunnels to be bound by DS Domains - which is likely to > be the dominant mode of operation in any case. Can you > provide additional clarification on this? > > A big part of my concern is that any LSR is likely > to need to support PHP. The Uniform model imposes additional > configuration requirements on penultimate hops. This is > bound to increase the configuration required in the network > as a whole. While configuration is an easy out in specifying > protocol, it's not usually a GOOD THING. What's more, the > specification should say what approach must be provided - so > that, for example, the need to specify a standard MIB for > configuring the required information is clear. > > -- > Eric Gray
|
|