RE: More comments/questions on DS-TE solution draft

[Jim Boyle <jboyle@pdnets.com>]

On Mon, 17 Jun 2002, Francois Le Faucheur wrote:
>
> When I drafted new text last Friday to reflect that point, I also noticed
> the optionality wasn't well expressed. Here is the text I came up with.
> Could you check it out:
>
> "
> A DS-TE LSR which elects to advertise Bandwidth Constraints MUST use the
> new "Bandwidth Constraints" sub-TLV to do so. For example, where a Service
> Provider deploys DS-TE with two active CTs, only two Bandwidth Constraints
> per link would be meaningful (assuming, for instance, the Russian Doll
> Bandwidth Constraint Model defined in section 9). Assuming the Service
> Provider elects to advertise Bandwidth Constraints, the "Bandwidth
> Constraints" sub-TLV would then be used and should contain BC0 and BC1.
>
> A DS-TE LSR which elects to advertise Bandwidth Constraints MAY also
> include the existing "Maximum Reservable Bw" sub-TLV. This may be useful in
> migration situations where some LSRs in the network are not DS-TE capable
> (see Appendix G) and thus do not understand the new "Bandwidth Constraints"
> sub-TLV. The DS-TE LSR MUST set the value of the "Maximum Reservable Bw"
> sub-TLV to the same value as the one for BC0 encoded in the "Bandwidth
> Constraints" sub-TLV.

I worry about removing the Max reservable BW sub-TLV, even though it
is redundant.  Any concern about implementations which expect it?
Maybe we should always include it, regardless of if one chooses to
additionally advertise a BC sub-TLV?

>
> A DS-TE LSR receiving both the old "Maximum Reservable Bw" sub-TLV and the
> new "Bandwidth Constraints" sub-TLV for a given link MAY ignore the
> "Maximum Reservable Bw" sub-TLV.
> "
>
> While we're on that section, here is what I drafted for that same section
> to reflect the discussion on multiple BC Models being allowed:
>
> "A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a Bandwidth
> Constraint Model Id which does not match the Bandwidth Constraint Model it
> currently uses, MAY generate a warning to the operator reporting the
> inconsistency between Bandwidth Constraint Models used on different links.
> If the DS-TE LSR does not support the Bandwidth Constraint Model designated
> by the Bandwidth Constraint Model Id, or if the DS-TE LSR does not support
> operations with multiple simultaneous Bandwidth Constraint Models, the
> DS-TE LSR MUST discard the corresponding TLV.
> "

change the last Must to May.  Afterall, nothing is stopping a head end
who doesn't understand a remote bandwidth constraint model from still
signalling against bandwidth that is advertised as available to a
specific TE Class.

>
> > > to optionnaly allow advertisement of both the new Bandwidth Constraints"
> > > sub-TLV and the old "Max Reservable Bw" in case there may be some
> > > non-DSTE-capable LSR in the network. right?

yes.

> > >
> >
> >.....
> >
> > > I guess we may add some text saying that a DS-TE LSR should only make use
> > > of Unreserved Bw [i] if there is a BC advertsied for the CT of that
> > > TE-class on the corresponding link. right ?
> >
> >Hmmm.  I think we're heading towards option (2) of the thread in:
> >
> >http://ops.ietf.org/lists/te-wg/te-wg.2002/msg00017.html
> >
> >The BC sub-object should remain optional.  I like the philosophy of
> >just checking the reservable bandwidth at the appropriate priority or
> >te-class (for standard and dste routers respectively), w/o *having* to
> >do all sorts of other checks.
>
> I woudl also like to see the BC sub-TLV being optional in the general case.
> What I am proposing is that:
>          - in normal DS-TE deployment where all LSRs have been upgraded and
> are DS-TE capable, then the BC sub-TLV is optional.
>          - in teh special case of migration, where some LSRs have not been
> upgraded and are not DS-TE capable, then BC sub-TLV needs to be used to
> help the DS-TE capable LSRs achieve  backwards compatibilitry. Clearly, the
> BC sub-TLV can stop be advertised once migration is completed.


If we start to use the BC sub-TLV to mean "I'm DSTE capable" - should
we maybe add a field to that effect - or just add another TLV to that
effect?