Subject: RE: TE/CT Configuration scalability

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Fri, 2 Jul 2004 09:42:25 +0100

Hi Jim, 

>> See 
>> http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-m
>> pls-te-req-07.txt
>> 
>> Section 5.1.7, this references section 4.1, of 
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-p
>> roto-07.txt
>> 
>> which doesn't exist.

Hm... Yes, we have a little numbering glitch in diff-te-proto-07. But
the authors of interas-mpls-te-req-07 had read it right: section 4.1.1
should be numbered 4.1.

Specifically:

"4.1.1. Link Parameters"  should read "4.1.  Link Parameters"

"4.1.2. Bandwidth Constraints (BCs)" should read "4.1.1. Bandwidth
Constraints (BCs)"

"4.1.3. Overbooking" should read "4.1.2. Overbooking"

So again, the reference in interas-mpls-te-req-07 is correct and should
be kept as is, and we will correct diff-te-proto.

Thanks

Francois

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Fri, 2 Jul 2004 09:42:25 +0100

Hello,

Expanding on Ina's response.

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 be that AS1
supports 4 preemption priorities within its AS for CT1, while AS2 only
supports 2 preemption priorities within its AS for CT1. 

Now, the two AS administrators certainly have to carefully agree on a
number of things before they can support inter-AS LSPs; like which CTs
they are allowed to use across ASes,  which preemption, how much maximum
bandwidth etc. But but this is how Diffserv works anyway independently
of DS-TE: for inter-AS Diffserv, operators have to agree on which
classes they want to share, which marking, what maximum rate for each,
and then configure mechansisms such as Traffic Conditioning accordingly.
DS-TE just fits in this existing Diffserv mode of operations.

Cheers

Francois

>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Ina Minei
>> Sent: jeudi 1 juillet 2004 19:26
>> To: [email-masked]
>> Cc: [email-masked]
>> 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 defined in the
>> te-proto draft. If instead of only advertising 8 values 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 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 matrix across
>> domains.
>> 
>> 			Ina
>> 
>> On Thu, 1 Jul 2004 [email-masked] 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 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
>> >
>> >
>> 
>>

---

From: [email-masked]
Date: Sun, 4 Jul 2004 11:28:24 +0300

As far as I can see there is a considerable difference bteween the inter-AS
Diffserv case and the inter-AS DS-TE case.

In Diffserv, the DIFFSERV TLV uses a standard PSC coding.  This promotes
the possibility of  agreement between the AS. They have to agree on the
PSC/Classes implemented and perhaps on policing, etc. There are no coding
issues.

In the DS-TE, there is no standard CLASSTYPE coding.  As Tony Li writes, a
"standard" mapping may be useful. But given that the idea of TE/CT is to
define a  limited number of combinations from a set prevalent alternatives,
this may be difficult.  In the absence of a standard mapping, it is
presumably necessary to have a mechanism to explicitly map between the
TE/CT codes of every AS pair.

Do you agree that this is required? if so, is it feasible?

                                                                                                        
                      "Francois Le                                                                      
                      Faucheur                 To:      "Ina Minei" <[email-masked]>,                  
                      \(flefauch\)"            <[email-masked]>                              
                      <flefauch@cisco.         cc:      <[email-masked]>, "FLF"                     
                      com>                     <[email-masked]>                                     
                                               Subject: RE: TE/CT Configuration scalability             
                      02/07/2004 11:42                                                                  

Hello,

Cheers

Francois

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Mon, 5 Jul 2004 08:03:15 +0100

>> In Diffserv, the DIFFSERV TLV uses a standard PSC coding.  

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

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
>>                       com>                     
>> <[email-masked]>