RE: -proto-05: Final Format of "Bandwidth Constraints" sub-TLV

[Rahul Aggarwal <rahul@juniper.net>]

Hi Francois,

> >> > Reserved field. See "New Format Without Bitmap" below.
> >> >
> >> > But it occurred to me that we could take advantage of one
> >> of the added
> >> > bytes to provide a bit-map of which BC constraints are
> >> actually included
> >> > in the sub-TLV. That way, if it happens that only CT0 and
> >> CT7 are used
> >> > (and thus only BC0 and BC7 are configured), the LSR could
> >> include only
> >> > BC0 and BC7 in the sub-TLV (rather than be forced to
> >> include all 8 BCs
> >> > as assumed by current format). See "New Format With Bitmap" below.
> >> >
> >> > I am leaning towards "new Format WITH Bitmap".
> >> >
> >> > Anyone has issues with "New Format With Bitmap"?
> >> > Other thoughts/comments?
> >> >
> >> >
> >>
> >> It is not clear why an operator would want to configure non contigous
> >> class types ?
>
> To set aside an intermediate Class-Type for potential future use.
>
> Imagine operator O runs an packet infrastructure used for (i) providing Internet Service and
(ii) carry PSTN Voice Trunks. O has deployed Diff-Serv in the core with EF+BE.
> O starts deploying DS-TE with RDM and has decided that (for now), he will build Voice tunnels
and Best Effort Data tunnels. Operator could use CT1 and CT0 and associate Voice Tunnels with CT1.
> However, next year O introduces a Premium 2547 IP VPN Service and wants to build separate
tunnels for Premium Data (supported with AF). O wants to have a CT for Premium Data which is in
between the CT for Voice and the CT for Best-Effort (ie Voice<BC2, Voice+Premium<BC1,
Voice+Premium+BE<BC2) . So O needs to change all his Best Effort Data tunnels and reconfigure
them to use CT2 so he can use CT1 for Premium Data.
> Same example could work if O was launching a Video class for which he wants separate tunnels
with a separate BC instead of the 2547 IP VPN Service.


> So at initial DS-TE deployment, O may want to use CT3 for Voice and CT0 for Best Effort Premium
to save CT1 and CT2 for future use.
>

To save CT1 and CT2 for future use the operator can announce the BCs such
that the bandwidth associated with CT1 and CT2 is 0. When the operator
starts using CT1 and CT2 the bandwidth can be announced appropriately. The
bitmap is not needed to do this.

Merci !

rahul

> I'd expect setting aside CTs when deploying DSTE with RDM (or any BC Model with ordered CTs) to
be fairly common practise. The bit map would be useful in these cases.
>
> No?
>
> Cheers
>
> Francois
>
> >> The new format without the bitmap seems
> >> preferable, as the
> >> bitmap may not be useful in practice.
> >>
> >> Thanks,
> >> rahul
> >>
> >>
> >>
> >> > Old format (as per -proto-05):
> >> > ==============================
> >> > "
> >> > "Bandwidth Constraints" sub-TLV:
> >> > - Bandwidth Constraint Model Id (1 octet)
> >> > - Bandwidth Constraints (Nx4 octets)
> >> > "
> >> >
> >> > New Format Without Bitmap:
> >> > ==========================
> >> > "
> >> > "Bandwidth Constraints" sub-TLV:
> >> > - Bandwidth Constraints Model Id (1 octet)
> >> > - Reserved (3 octets)
> >> > - Bandwidth Constraints (Nx4 octets)
> >> > + some text explaining that "Reserved" is to be set to
> >> zero on transmit,
> >> > ignored on receipt.
> >> > "
> >> >
> >> > New Format With Bitmap:
> >> > =======================
> >> > "
> >> > "Bandwidth Constraints" sub-TLV:
> >> > - Bandwidth Constraints Model Id (1 octet)
> >> > - Bandwidth Constraints Bitmap (1 octet)
> >> > - Reserved (2 octets)
> >> > - Bandwidth Constraints (Nx4 octets)
> >> > + some text explaining that :
> >> > 	* "Reserved" is to be set to zero on transmit, ignored on
> >> > receipt.
> >> > 	* "Bitmap" is a set of 8 flags each indicating if the
> >> > corresponding BC is included in sub-TLV (eg. 10100001
> >> means that BC0,
> >> > BC2 and BC7 will be included).
> >> > "
> >> >
> >> > Cheers
> >> > Francois
> >> >
> >> >
> >>
>