headers
rfc-editor | 17 Nov 2005 03:05
Favicon

RFC 4216 on MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements


A new Request for Comments is now available in online RFC libraries.

        RFC 4216

        Title:      MPLS Inter-Autonomous System (AS)
                    Traffic Engineering (TE) Requirements
        Author(s):  R. Zhang, Ed., J.-P. Vasseur, Ed.
        Status:     Informational
        Date:       November 2005
        Mailbox:    raymond_zhang <at> infonet.com, jpv <at> cisco.com
        Pages:      29
        Characters: 64640
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tewg-interas-mpls-te-req-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4216.txt

This document discusses requirements for the support of inter-AS
MPLS Traffic Engineering (MPLS TE).  Its main objective is to
present a set of requirements and scenarios which would result in
general guidelines for the definition, selection, and specification
development for any technical solution(s) meeting these requirements
and supporting the scenarios.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This memo provides information for the Internet community.  It does
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Charlap | 29 Nov 2005 17:56

RSVP-TE: specifying links in EROs

I've been reading through RFCs 3209, 3473, and 3477.

I can't seem to find any mechanism that an originating node can use to 
fully specify both the nodes and links of an ERO.  All the discussion 
deals with abstract nodes, and doesn't say a thing about how to select 
specific links between the nodes.

Clearly, the chosen link must satisfy the LSP's constraints (QoS, CoS, 
link colors, etc.), but when there are multiple compatible links, the 
RFCs appear to be silent.

If an originating node wishes to fully specify the path through the 
network, down to the granularity of individual links, is there an 
RFC-specifie behavior that will allow this?

One can obviously build RSVP-TE with rules to permit this (such as 
selecting interfaces that exactly match ERO subobjects when there is a 
compatible match), but I can't find anything in the RFCs that discuss 
this.  They all merely state that the subobjects define abstract nodes 
(which may be a single router), but with no more granularity than that.

Surely, given the requirements and design goals of GMPLS, there must be 
a mechanism that I've missed.  Can anyone help?

-- David
Permalink | Reply | 0 comments |
headers
David Charlap | 29 Nov 2005 21:40

Re: RSVP-TE: specifying links in EROs

This is what I thought.  I also thought that using ERO subobjects with 
/32 addresses matching interface addresses would work.  But I can't find 
anything in the RFCs that documents this behavior.

I also thought the IF-ID subobject (used for unnumbered links) would 
work, but the RFC says otherwise.  It says only that the subobject can 
be used to define an abstract node via router-ID and IF-ID, and says 
that the actual ERO processing does not change from what was previously 
documented.

-- David

Don Fedyk wrote:
> Hi David
> 
> It was my impression that if you use numbered links, the ERO could
> specify the links as well. 
> 
> Don 
> 
> 
> 
> 
>>-----Original Message-----
>>From: owner-te-wg <at> ops.ietf.org 
>>
>>I've been reading through RFCs 3209, 3473, and 3477.
>>
>>I can't seem to find any mechanism that an originating node 
>>can use to
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Charlap | 30 Nov 2005 18:11

Re: RSVP-TE: specifying links in EROs

It would appear that I didn't phrase my original question clearly 
enough, given the nature of several responses I've received so far. 
Hopefully this will be better:

Suppose there are two routers with three links between them

       _________            _________
      |        A|----------|B        |
      |   R1   C|----------|D   R2   |
   ---|G       E|----------|F       H|----
      |_________|          |_________|

All of the interfaces have IDs (A-H).  These IDs may be IP addresses 
(numbered links) or they may be IF-IDs (unnumbered links).  Either way, 
they can all be uniquely identified.

If this would be an ATM network, it would be possible to signal a 
virtual circuit with or without specifying a particular link.  The DTL 
object (ATM equivalent of an ERO) can specify just node IDs, or it can 
specify port IDs as well.  If port IDs are specified, then the VC will 
be established over the link corresponding to that port.

What I can't find is some way of providing similar functionality in the 
MPLS world.

Clearly, if R1 and R2 are routable addresses acting as router IDs, and I
specify them in an ERO (R1, R2, ...), RSVP (running in R1) is free to
select any of the three links using whatever local criterial it
considers appropriate.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Tony Li | 30 Nov 2005 20:28
Picon
Gravatar

Re: RSVP-TE: specifying links in EROs

> Suppose there are two routers with three links between them
>
>       _________            _________
>      |        A|----------|B        |
>      |   R1   C|----------|D   R2   |
>   ---|G       E|----------|F       H|----
>      |_________|          |_________|
>
> Suppose, however, that the ERO instead consists of ingress interface
> addresses (G, B, ...) or of egress interface addresses (A, H, ...) or
> perhaps even both (G, A, B, H, ...).  In these cases, has the ERO
> specified that the LSP should be created over the A-B link?  Or are
> these examples no different from the case of using router addresses?

Yes, if the ERO contains interface addresses, that specifies the  
interfaces
to be used.

Tony
Permalink | Reply | 503 comments |
headers
David Charlap | 30 Nov 2005 21:11

Re: RSVP-TE: specifying links in EROs

Tony Li wrote:
>> Suppose there are two routers with three links between them
>>
>>       _________            _________
>>      |        A|----------|B        |
>>      |   R1   C|----------|D   R2   |
>>   ---|G       E|----------|F       H|----
>>      |_________|          |_________|
>>
>> Suppose, however, that the ERO instead consists of ingress interface
>> addresses (G, B, ...) or of egress interface addresses (A, H, ...) or
>> perhaps even both (G, A, B, H, ...).  In these cases, has the ERO
>> specified that the LSP should be created over the A-B link?  Or are
>> these examples no different from the case of using router addresses?
> 
> Yes, if the ERO contains interface addresses, that specifies the  
> interfaces to be used.

Could you point out the section of the RFC where this is stated?

As I wrote, this behavior seems to be a common practice, but I can't 
find any document that mandates this behavior.

-- David
Permalink | Reply | 6 comments |
headers
Adrian Farrel | 30 Nov 2005 21:47
Picon

Re: RSVP-TE: specifying links in EROs

David,

Tony is right (again).

You may want to take your discussion to the CCAMP WG where an I-D of what
addresses to use when in MPLS-TE/GMPLS is being put together based on
interop experience. The I-D covers EROs. It is still up for discussion.

Cheers,
Adrian
----- Original Message ----- 
From: "Tony Li" <tony.li <at> tony.li>
To: "David Charlap" <David.Charlap <at> marconi.com>
Cc: "IETF TE-WG List" <te-wg <at> ops.ietf.org>
Sent: Wednesday, November 30, 2005 7:28 PM
Subject: Re: RSVP-TE: specifying links in EROs

> > Suppose there are two routers with three links between them
> >
> >       _________            _________
> >      |        A|----------|B        |
> >      |   R1   C|----------|D   R2   |
> >   ---|G       E|----------|F       H|----
> >      |_________|          |_________|
> >
> > Suppose, however, that the ERO instead consists of ingress interface
> > addresses (G, B, ...) or of egress interface addresses (A, H, ...) or
> > perhaps even both (G, A, B, H, ...).  In these cases, has the ERO
> > specified that the LSP should be created over the A-B link?  Or are
> > these examples no different from the case of using router addresses?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Li | 1 Dec 2005 00:16
Picon
Gravatar

Re: RSVP-TE: specifying links in EROs


>> Yes, if the ERO contains interface addresses, that specifies the   
>> interfaces to be used.
>
> Could you point out the section of the RFC where this is stated?
>
> As I wrote, this behavior seems to be a common practice, but I  
> can't find any document that mandates this behavior.

David,

Please see RFC 791, page 24:

     That is, there must be a mapping between internet host addresses  
and
     network/host interfaces that allows several internet addresses to
     correspond to one interface.

This implies that any single IP address corresponds to a subset of  
the interfaces
on the router (typically only one).

The binding of an IP address to an interface has been argued to be an  
architectural
misfeature, but it is certainly a long term accepted facet of the IP  
architecture.

Tony
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Charlap | 1 Dec 2005 00:51

Re: RSVP-TE: specifying links in EROs

Tony Li wrote:
> 
> Please see RFC 791, page 24:
> 
> That is, there must be a mapping between internet host addresses and
> network/host interfaces that allows several internet addresses to
> correspond to one interface.
> 
> This implies that any single IP address corresponds to a subset of
> the interfaces on the router (typically only one).
> 
> The binding of an IP address to an interface has been argued to be an
> architectural misfeature, but it is certainly a long term accepted
> facet of the IP architecture.

This has nothing to do with MPLS or EROs.  The fact that interfaces are
numbered does not mean that an RSVP-TE ERO subobject is capable of
representing a single interface.

The only reference to link selection I've found is section 4.3.4.1 of
RFC 3209 ("Selection of the Next Hop").  It deals entirely with abstract
nodes:

     5) Interior of the Abstract Node Case: Otherwise, the node selects a
        next hop within the abstract node of the first subobject (which
        the node belongs to) that is along the path to the abstract node
        of the second subobject (which is the next abstract node). ...

Nothing in the ERO processing procedure mentions link selection at all.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tony Li | 1 Dec 2005 01:52
Picon
Gravatar

Re: RSVP-TE: specifying links in EROs


David,

> This has nothing to do with MPLS or EROs.  The fact that interfaces  
> are
> numbered does not mean that an RSVP-TE ERO subobject is capable of
> representing a single interface.

I'm unsure of the point that you're trying to make.  The semantics of  
the ERO
has been clear to numerous implementors along the way, as you yourself
have noted.  Simply put, if the path does not traverse the link  
specified by the
IP address, then it has not traversed the appropriate abstract node.

If you're arguing that the wording of the RFC could be clearer, I'll  
grant you
that, but it's a bit late as we don't revise issued RFCs.

If you're not looking for a clarification, I'm not sure how we can  
help you.

Regards,
Tony
Permalink | Reply | 2 comments |

Gmane