RE: TE/CT Configuration scalability
"Francois Le Faucheur \(flefauch\)" <[email protected]> Mon, 5 Jul 2004 08:03:15 +0100
| Newsgroups | gmane.ietf.tewg |
|---|---|
| Message-ID | <[email protected]> |
>>=20 >> As far as I can see there is a considerable difference=20 >> bteween the inter-AS >> Diffserv case and the inter-AS DS-TE case. >>=20 >> In Diffserv, the DIFFSERV TLV uses a standard PSC coding. =20 Let's forget MPLS for a second. In non-MPLS IP Diffserv, there is no signaling whatsoever across AS, with respect to Diffserv. Operators who wish to offer inter-AS Diffserv just agree on a common set of classes, markings, traffic contracts, QoS commitments, compensation, ...=20 Currently there is no "recommended/standard" set of Diffserv classes. It is up to each operator to decide what set of classes is optimum for their environment, and this choice, along with corresponding QoS commitments, is a strong differentiation factor. If, in the future, operators feel that it is desirable to convergence on a "recommended/standard" set of Diffserv classes and specify those, then we could look at how to support that set of classes when TE/DS-TE mechanisms are used. For now, I am not aware of the existence of such a "recommended/standard" set. I am not even sure that there is convergence among operators that it makes sense to specify that. Francois >> This promotes >> the possibility of agreement between the AS. They have to=20 >> agree on the >> PSC/Classes implemented and perhaps on policing, etc. There=20 >> are no coding >> issues. >>=20 >> In the DS-TE, there is no standard CLASSTYPE coding. As=20 >> Tony Li writes, a >> "standard" mapping may be useful. But given that the idea of=20 >> TE/CT is to >> define a limited number of combinations from a set=20 >> prevalent alternatives, >> this may be difficult. In the absence of a standard mapping, it is >> presumably necessary to have a mechanism to explicitly map=20 >> between the >> TE/CT codes of every AS pair. >>=20 >> Do you agree that this is required? if so, is it feasible? >>=20 >> Lionel Silman, System, Optical Networks Division, ECI Telecom >>=20 >>=20 >>=20 >> =20 >> =20 >> "Francois Le =20 >> =20 >> Faucheur To: "Ina=20 >> Minei" <[email protected]>, =20 >> \(flefauch\)" =20 >> <[email protected]> =20 >> <flefauch@cisco. cc: =20 >> <[email protected]>, "FLF" =20 >> com> =20 >> <[email protected]> =20 >> Subject: RE:=20 >> TE/CT Configuration scalability =20 >> 02/07/2004 11:42 =20 >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >>=20 >>=20 >> Hello, >>=20 >> Expanding on Ina's response. >>=20 >> The TE-Class Mapping need NOT be the same in different Autonomous >> Systems which are span by a given inter-AS DS-TE LSP. It may=20 >> be that AS1 >> supports 4 preemption priorities within its AS for CT1,=20 >> while AS2 only >> supports 2 preemption priorities within its AS for CT1. >>=20 >> Now, the two AS administrators certainly have to carefully agree on a >> number of things before they can support inter-AS LSPs; like=20 >> which CTs >> they are allowed to use across ASes, which preemption, how=20 >> much maximum >> bandwidth etc. But but this is how Diffserv works anyway=20 >> independently >> of DS-TE: for inter-AS Diffserv, operators have to agree on which >> classes they want to share, which marking, what maximum rate=20 >> for each, >> and then configure mechansisms such as Traffic Conditioning=20 >> accordingly. >> DS-TE just fits in this existing Diffserv mode of operations. >>=20 >> Cheers >>=20 >> Francois >>=20 >> >> -----Original Message----- >> >> From: [email protected] >> >> [mailto:[email protected]] On Behalf Of Ina Minei >> >> Sent: jeudi 1 juillet 2004 19:26 >> >> To: [email protected] >> >> Cc: [email protected] >> >> Subject: Re: TE/CT Configuration scalability >> >> >> >> >> >> Lionel, >> >> >> >> I assume your question is "can I establish an inter-as >> >> diffserv-te >> >> lsp given the requirement for uniform TE-class >> >> configuration" ? The answer >> >> is yes. >> >> >> >> The reason for having a requirement for uniform TE-Class >> >> configuration is because of the way IGP siganling is=20 >> defined in the >> >> te-proto draft. If instead of only advertising 8 values=20 >> out of the 64 >> >> possible (ct, prio) combinations we would have advertised >> >> all 64, there >> >> wouldn't have been the concept of TE-classes or the >> >> requirement to keep >> >> them uniform. >> >> >> >> The only thing we get from the requirement is=20 >> to be able to >> >> consistently set up an LSP conforming to some SLAs within >> >> one domain. So >> >> what happens when you cross to a different domain? All you >> >> need to do is >> >> translate the LSP's SLAs to the necessary parameters in the >> >> new domain. >> >> >> >> There is no requirement to signal the TE-class=20 >> matrix across >> >> domains. >> >> >> >> Ina >> >> >> >> On Thu, 1 Jul 2004 [email protected] wrote: >> >> >> >> > >> >> > >> >> > >> >> > >> >> > draft-ietf-tewg-diff-te-proto-07, "Protocol extensions for >> >> support of >> >> > Differentiated-Service-aware MPLS Traffic Engineering" states:- >> >> > >> >> > "To ensure coherent DS-TE operation, the network=20 >> administrator MUST >> >> > configure exactly the same TE-Class Mapping on all LSRs of >> >> the DS-TE >> >> > domain" >> >> > >> >> > How does this idea of identical TE/CT configuration work >> >> over multiple >> >> > domains? Is there any possibility of interoperability? >> >> > >> >> > >> >> ------------------------------------------------------------- >> >> --------------------------------------- >> >> > >> >> > Lionel Silman, System, Optical Networks Division, ECI Telecom >> >> > Tel Work: +972 (3) 9266007; Home: +972 (3) 6417464 >> >> > >> >> > >> >> >> >> >>=20 >>=20 >>=20 >>=20