Subject: RE: [RADIR] General TE definition

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 9 May 2007 13:54:30 -0400

I like johns tweaked version.

As for the long version.  I like it.  I dont care if it goes in the statement or in one of the added supporting documents though. I just believe the long version should be included somewhere in relation to the problem statement doc.

As for the long one.   Two things:

1. I dont like the word artificial in this sentence.  Its a real path and a valid one and most likely a better one for the network, otherwise it wouldnt have been done.  >Traffic engineering (TE) is artificially influencing the natural path<
Could we possibly replace that word with "manualy"?

2. Only one paragraph reads a little rough.  I think maybe its grammatical errors that make it read so rough and it could use a little fixing.  Just not sure yet what to fix.

>Outbound inter-AS TE is typically accomplished but using the internal IGP
metrics to chooses the shortest exit for two equally good BGP
paths.  Tweaking the IGP metrics will cause more or less of the network to
choose a specific exit point as shorter for two equally good BGP
paths.  Additional traffic can be moved by applying some policy to
depreference, or filter certain routes from specific BGP peers.<

~Marla

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Wednesday, May 09, 2007 1:22 AM
To: Jason Schiller
Cc: Erik Nordmark; [email-masked]; Jason Schiller
Subject: Re: [RADIR] General TE definition

Jason,

Either the shorter or longer version WFM.  I kind of like the shorter  
version because, well, it's shorter.  There's no need (IMO) to make  
this document a tutorial on all possible forms of TE -- it just needs  
to clarify what form of TE we are talking about.

One possible tweak to the shorter version to make this a bit more  
explicit:

"In this document, 'traffic engineering' (TE) refers to the current  
practice of inbound, inter-AS traffic engineering.  This is  
accomplished by placing more specific routes in the routing table and/ 
or increasing the frequency of routing updates in order to control  
inbound traffic at the boundary of an Autonomous system (AS)."

But any of the different versions are fine.

--John

On May 9, 2007, at 12:30 AM, Jason Schiller wrote:

> On Tue, 8 May 2007, Erik Nordmark wrote:
>
>> Should we make #2 more specific in the text above i.e.
>> Inbound traffic engineering (TE) ...
>>
>> and also add some text about Outbound traffic engineering saying  
>> that it
>> doesn't (normally?) have any effects outside of the AS itself?
>>
>>     Erik
>
> Erik,
>
> I have no objections to either suggestion...
>
> In the call today we were discussing a short general definition of  
> "TE'
> for in the problem statement, and were planning on having a more  
> detailed
> description of TE in the "pressures on the routing table" section.
>
> I am happy to include your suggestions in either or both places.
>
> I'm not sure how detailed we want to get but how is this:
>
> Traffic engineering (TE) is artificially influencing the natural  
> path that
> traffic is forwarded on.  TE is usually divided into internal TE and
> inter-AS TE.
>
> Internal TE is typically accomplished within the Interior Gateway  
> Protocol
> (IGP) and all information is kept local to the Autonomous System
> (AS).  Since the amount of state in the IGP is relatively small,  
> and the
> information is kept local this is typically not a large factor in  
> routing
> scale.
>
> Inter-AS TE is used at Autonomous System (AS) boundaries, and has a  
> direct
> impact on the routing table.  Inter-AS TE is typically divided into  
> two
> types inbound inter-AS TE and outbound inter-AS TE.
>
> Inbound inter-AS TE is typically accomplished by placing more specific
> routes in the routing table and/or increasing the frequency of routing
> updates in order to control inbound traffic at the boundary of an
> Autonomous system (AS).
>
> Outbound inter-AS TE is typically accomplished but using the  
> internal IGP
> metrics to chooses the shortest exit for two equally good BGP
> paths.  Tweaking the IGP metrics will cause more or less of the  
> network to
> choose a specific exit point as shorter for two equally good BGP
> paths.  Additional traffic can be moved by applying some policy to
> depreference, or filter certain routes from specific BGP peers.
>
> -----
>
> First attempt for reference
>
> Traffic engineering (TE) is accomplished by placing more specific  
> routes
> in the routing table and/or increasing the frequency of routing  
> updates in
> order to control inbound traffic at the boundary of an Autonomous  
> system
> (AS).
>
> notes from previous email:
>
> This is not exactly what I said on the call, and here is why:
>
> 1. I wanted to distingusih between internal traffic engineering done
> primarily in the IGP vs. inter-AS traffic engineering at the inter- 
> domain
> level.
>
> 2. I included the word "inbound".  The extra more specifics, and the
> frequency of changing them is an attempt to change inbound TE.   
> Outbound
> TE is often a function of your IGP for shortest exit for equally good
> routes, or some policy to depreference, or filter certain routes from
> specific BGP peers.
>
>
> ___Jason
>
>
>
> ====================================================================== 
> ====
> Jason Schiller                                               (703) 
> 886.6648
> Senior Internet Network Engineer                         fax:(703) 
> 886.0512
> Public IP Global Network Engineering                        
> [email-masked]
> UUNET / Verizon                          
> [email-masked]
>
> The good news about having an email address that is twice as long  
> is that
> it increases traffic on the Internet.
>
>
>
>
> _______________________________________________
> RADIR mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/radir

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

---

From: Jason Schiller <[email-masked]>
Date: Wed, 09 May 2007 16:25:51 -0400 (EDT)

Marla,

I am certain any gramtical fix will be fine (as well as spelling fixes
;-)).... 

As for artificial, yes I agree that the path is "real" and not 
"artificial"... the word I was looking for is "not the natural" path.  I
guess by artificial I was attempting to mean "not natural", but now that
you point it out, I do also read it as "fake".       

I think manual works ok.  It certainly removes the confusion, and the
phrase "natural path" at the end is enough to convey my intended thought.

Thanks for pointing that out.  :-)   
     
___Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Wed, 9 May 2007, Azinger, Marla wrote:

> Date: Wed, 09 May 2007 13:54:30 -0400
> From: "Azinger, Marla" <[email-masked]>
> To: John G. Scudder <[email-masked]>, Jason Schiller <[email-masked]>
> Cc: Erik Nordmark <[email-masked]>, [email-masked],
>      Jason Schiller <[email-masked]>
> Subject: RE: [RADIR] General TE definition
> 
> 1. I dont like the word artificial in this sentence.  Its a real path
> and a valid one and most likely a better one for the network, otherwise
> it wouldnt have been done.  >Traffic engineering (TE) is artificially
> influencing the natural path<