[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Jim,

At 12:30 17/06/2002 -0400, Jim Boyle wrote:

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?
Today Max Reservable is only optional anyway, so I don't think any implementation should "always expect it".
Current text allows:
- in the interim, during migration and interoperation with old LSRs, you may advertise it.
- in the long run when all LSRs are upgraded, you don't have to advertise it, but you may if you want.
I don't think we should mandate always advertising it since it is completetly redundant when all LSRs are DSTE capable. We've had lots of pressure to minimise IGP extensions, so I am really relunctant to keep something redundant in there.
Kireeti made a similar point a while back when the earlier draft proposed a different variation (ie BC0 stayed in Max Reservable and BC-sub-TLV only advertised BC1, BC2,...) : Kireeti pointed out it would be simpler in the long run with a single sub-TLV for all BCs.



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

Fair enough. Done.
>
> > > 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?
We could certainly do that. This is the approach of explicitely signaling "DS-TE capability" on new LSRs. The drawback I see of such an approach is that it would result in some additional information being always advertised in the IGP for ever and ever, just to resolve a temporary migration issue.

The approach currently proposed is more like inferring "DS-TE incapability" of old LSRs. It forces use to use an existing sub-TLV in a particular way during transition, but the benefit is that once LSRs are all upgraded you are back to a minimised IGP signaling ie you can leave with ONLY advertising the 8bw values of "Unreserved BW " sub-TLV and that's it.
Again, because we had so much pressure to minimise IGP signaling, I favor the current approach.

No?

Francois