headers
shilpa goel | 4 Dec 2006 06:23
Picon

: label space configuration

Hi..

  Can you please give me an insight as to how label space (per interface or per platform) is configured in a LSR i.e. what all considerations need to be taken into account:

for 2 cases-
    -LSR consisting of only ethernet ports
    -LSR consisting of both ATM and ethernet interfaces

thanks and regards,
Shilpa

Permalink | Reply | 0 comments |
headers
Mohammed Shahnawaz | 5 Dec 2006 14:28
Favicon

: Tagging of BGP extended community

 

Hi,

 

Can someone explain how routers support tagging of multiple BGP extended communities for VPN4 routes using a single interface between PE and CE.  Please provide some documents as well, if possible.

 

 

Thanks & Regards,

 

Shahnawaz

 

 

 

Permalink | Reply | 0 comments |
headers
Truman Boyes | 5 Dec 2006 20:42
Favicon

Re: : Tagging of BGP extended community

Hello,

The tagging of MBGP extended communities for VPNv4 routes is controlled within the BGP task by policy. Keep in mind that prefixes may have single extended communities for VPNs, or additive policy may allow multiple communities to be associated with the prefix. All of this policy is completely interface agnostic. For example, an operator may wish to export (redistribute) a set of static routes with multiple extended communities. 

Each extended community may be associated with a different VPN, thus allowing the exported route to be received and installed in the different VRFs.

Say for example that prefix 10.10.10/24 has the following communities: 'target:65009:100' and 'target:65009:200'. Assuming there are two VRFs configured (RED and BLUE), and RED is importing all prefixes with extended community 'target:65009:100' and BLUE is importing 'target:65009:200'. 

The 10.10.10/24 prefix would be imported into both BLUE and RED VRFs.

You might want to read the following:



Cheers,
Truman



On 6/12/2006, at 2:28 AM, Mohammed Shahnawaz wrote:

-->

 

Hi,

 

Can someone explain how routers support tagging of multiple BGP extended communities for VPN4 routes using a single interface between PE and CE.  Please provide some documents as well, if possible.

 

 

Thanks & Regards,

 

Shahnawaz

 

 

 


Permalink | Reply | 0 comments |
headers
shilpa goel | 12 Dec 2006 05:03
Picon

Re: : label space configuration

Hi,

 Thanks for the clarification. I still have 2 doubts in this.

Firstly, what is meant by the line  'as the router knows about all of them'?  (2nd para)

Also, this is clear that for ATM, interface label space should be used but why should platform wide labelling be used in an Ethernet configuration i.e. why can't we use interface label space for ethernet also thereby seeking the same advantage as we are getting for ATM?

thanks,
Shilpa

On 12/4/06, Roger Williams (rogwilli) <rogwilli <at> cisco.com> wrote:
Shilpa, platform-wide labeling is used in an Ethernet configuration, whereas port or interface lablespace is used for ATM.
 
Basically what that means is that for Ethernet a given router advertises its whole self with one label upstream. All ports would be covered under that single label advertisement, as the router knows about all of them. And it is done as soon as the underlying IGP routing protocol knows there are routes to be labeled, not waiting for the demands of traffic to build label paths.
 
With ATM the doling out of labels is much more conservative, and done only when requested by traffic demand. The reason for this is the limited number of VCs that an ATM switch can support (I think 4096). The labels point to a VC underneath it all. Since there is no routing done at the Layer 2 of an ATM switch, each label is used as a per-interface advertisement, which effectively is a per-VC advertisement.
 
I hope that helps.
 
Roger.

From: shilpa goel [mailto:shilpa07 <at> gmail.com]
Sent: Monday, December 04, 2006 12:24 AM
To: mpls <at> uu.net; mpls-ops <at> mplsrc.com; mpls <at> lists.ietf.org
Subject: [MPLS-OPS]: label space configuration

Hi..

  Can you please give me an insight as to how label space (per interface or per platform) is configured in a LSR i.e. what all considerations need to be taken into account:

for 2 cases-
    -LSR consisting of only ethernet ports
    -LSR consisting of both ATM and ethernet interfaces

thanks and regards,
Shilpa

Permalink | Reply | 0 comments |
headers
Santanu.Ganguly | 14 Dec 2006 10:09
Favicon

RE: Re: [MPLS-OPS]: label space configuration

Hi Shilpa,
 
1) I suspect what Roger means by 'as the router knows about all of them' is the following:
 
Generally speaking ther are 2 types of label spaces, as we all know: Per-Interface & Per-Platform. Per-platform assigns labels
from a platform-wide pool of labels and  uses resources that are shared across the platform. Hop-by-hop best-effort IP/MPLS
forwarding is an example of using the per-platform label space....
 
Frame based MPLS interfaces ( POS, Ethernet, fast Ethernet etc...:) use a per-platform label space , which basically means that the label space is router-wide and assigned from a unique pool of labels in the LSR; the label can used on ANY interface. The LFIB has no information about the incoming interfaces ( i think...:-))
 
However, the nature of the labels dolled out on LC-ATM interfaces stops us from using per-paltform label space. 2 LC-ATM interfaces can use the same VPI/VCI pair as a label. As such , LC-ATM interfaces use per-interface labels which has non-zero label space ID.
 
Note : In some router platforms it is possible to manually configure something like a "mpls ldp label-space-id < ID number> " on frame based interfaces if indeed this becomes an issue...in case a labe-space is not defined it takes the deafult value ( 0 for ethernet)...
 
2) Consider the scenario of 2 routers connected back to back via 2 links of Etherent. Without the present definition of Etherenet
label space, they will open up 2 different LDP sessions, for which they may require to open up 2 TCP sessions..., which really
would be unnecessary....maybe :-)
 
3) As far as I know, historically speaking, IETF developed a series of solutions for various Layer 2 VPN applications including
pseudowire emulations. I think Cisco Systems also has developed an alternate pseudowire emulation ( L2TPv3 ?)...I am sure there
are enough "cisco.com " email addresses here in this forum to correct me if I am wrong or to elaborate on this if i am not :-)
 
Cheers :-)
 
santanu
 
Santanu Ganguly
Swisscom Fixnet Wholesale
Binz Ring 17
8045 Zurich
Switzerland
 

From: shilpa goel [mailto:shilpa07 <at> gmail.com]
Sent: Tuesday, December 12, 2006 5:03 AM
To: Roger Williams (rogwilli); mpls <at> UU.NET; mpls-ops <at> mplsrc.com
Subject: [mpls] Re: [MPLS-OPS]: label space configuration

Hi,

 Thanks for the clarification. I still have 2 doubts in this.

Firstly, what is meant by the line  'as the router knows about all of them'?  (2nd para)

Also, this is clear that for ATM, interface label space should be used but why should platform wide labelling be used in an Ethernet configuration i.e. why can't we use interface label space for ethernet also thereby seeking the same advantage as we are getting for ATM?

thanks,
Shilpa

On 12/4/06, Roger Williams (rogwilli) <rogwilli <at> cisco.com> wrote:
Shilpa, platform-wide labeling is used in an Ethernet configuration, whereas port or interface lablespace is used for ATM.
 
Basically what that means is that for Ethernet a given router advertises its whole self with one label upstream. All ports would be covered under that single label advertisement, as the router knows about all of them. And it is done as soon as the underlying IGP routing protocol knows there are routes to be labeled, not waiting for the demands of traffic to build label paths.
 
With ATM the doling out of labels is much more conservative, and done only when requested by traffic demand. The reason for this is the limited number of VCs that an ATM switch can support (I think 4096). The labels point to a VC underneath it all. Since there is no routing done at the Layer 2 of an ATM switch, each label is used as a per-interface advertisement, which effectively is a per-VC advertisement.
 
I hope that helps.
 
Roger.

From: shilpa goel [mailto:shilpa07 <at> gmail.com]
Sent: Monday, December 04, 2006 12:24 AM
To: mpls <at> uu.net; mpls-ops <at> mplsrc.com; mpls <at> lists.ietf.org
Subject: [MPLS-OPS]: label space configuration

Hi..

  Can you please give me an insight as to how label space (per interface or per platform) is configured in a LSR i.e. what all considerations need to be taken into account:

for 2 cases-
    -LSR consisting of only ethernet ports
    -LSR consisting of both ATM and ethernet interfaces

thanks and regards,
Shilpa

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Aveer Jain | 18 Dec 2006 06:12
Picon

: how to decide whether oneself is egress

Hi All,

 

A naive question on LDP behavior, if router (say R2) is running in Down-stream unsolicited distribution and Ordered Control mode, how it decide that for certain FECs it is owner and has to advertise those to its upstream peers. Is it all the directly connected routes?, if so then if  there is a connection to a non-mpls domain through this router then label for those routes would not be advertised to my upstream?

 

 

R1 -------------- R2 -------------------non-mpls-interface ----R3 ---------------- Y (another network connected)

                     |

                     |

                    X (network connected directly)

 

Is this implementation specific … I don't remember if RFC 3036 or 3032 says something about it.

 

Thanks,

Aveer Jain
Permalink | Reply | 0 comments |
headers
shilpa goel | 22 Dec 2006 11:21
Picon

: basic query about RSVP

Hi,

  I have few basic doubts regarding the functioning of RSVP-TE:

In RSVP as I understand "Link Admission Control" is used within the PATH message and the bandwidth value is included in the sender's Tspec field. This bandwidth is moved to a waiting pool untill a RESV mesage is received. Otherwise, a path error  message will be sent upon reception of RESV.  With respect to this understanding, I have the following doubts:

1)What actual benefits do we achieve by "Receiver Initiated Reservation Style"? Why cannot we perform Admission Control and Policy control during the flow of Path messages only?

2)When the path message is moving downstream and the required bandwidth is available
then it is moved to the waiting pool, but what if the required bandwidth is not
available why the error message has to wait for the RESV message from the downstream?
In this way we are unnecessarily blocking the network with the control packets if we
know that required reservation could not be made in the first place?

thanks,
Shilpa

Permalink | Reply | 0 comments |

Gmane