The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2003-Feb> msg00174



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Fwd: Re: RE: Route Distinguisher Questions

  • From: "john smith" <johnsmith0302@hotmail.com>
  • Date: Mon, 24 Feb 2003 13:19:01 +0530
  • Cc: "MPLS-ops Mailing List" <mpls-ops@mplsrc.com>
  • Resent-Date: Mon, 24 Feb 2003 04:12:30 -0500
  • To: <raszuk@cisco.com>
  • X-OriginalArrivalTime: 24 Feb 2003 07:47:06.0775 (UTC) FILETIME=[EDBC3A70:01C2DBD8]
  • X-Originating-IP: [203.124.140.38]

hi Robert,

seems we are on the same side in somethings... :-)
inline.....

----- Original Message -----
From: Robert Raszuk <raszuk@cisco.com>
To: john smith <johnsmith0302@hotmail.com>
Cc: MPLS-ops Mailing List <mpls-ops@mplsrc.com>
Sent: Monday, February 24, 2003 10:14 AM
Subject: Re: Fwd: Re: RE: [MPLS-OPS]: Route Distinguisher Questions


> John,
>
> > How many bits does the RD field have?? :-o are they enuf to put an AS #
in
> > it? and make it globally unique?
>
> 8 bytes = 64 bits ... :).

:o) so why did we ever make RT?

>
>    The RDs are structured so that every service provider can administer
>    its own "numbering space" (i.e., can make its own assignments of
>    RDs), without conflicting with the RD assignments made by any other
>    service provider.  An RD consists of a two-byte type field, an
>    administrator field, and an assigned number field.  The value of the
>    type field determines the lengths of the other two fields, as well as
>    the semantics of the administrator field.  The administrator field
>    identifies an assigned number authority, and the assigned number
>    field contains a number which has been assigned, by the identified
>    authority, for a particular purpose.  For example, one could have an
>    RD whose administrator field contains an Autonomous System number
>
> Rosen & Rekhter              Informational                      [Page 9]
> RFC 2547                     BGP/MPLS VPNs                    March 1999
>
>    (ASN), and whose (4-byte) number field contains a number assigned by
>    the SP to whom IANA has assigned that ASN.  RDs are given this
>    structure in order to ensure that an SP which provides VPN backbone
>    service can always create a unique RD when it needs to do so.
>    However, the structuring provides no semantics. When BGP compares two
>    such address prefixes, it ignores the structure entirely.

.............so u still need "RT" ??? (well yeah it has more bits than RD
;-) )

.......was it made for CoC and Multiple ASes, or was it made for something
else????

and now that we maybe able to "filter on RD" since they will be globally
unique..why not put RT to a better use...any ideas how?

...............i see it having a greater significance... in terms of
community scenarios.....

>
> > so we still have a label stack, the LDP gives u the LSP to the end PE
and
> > the inner label to identify the VRF is passed by BGP?
> > is this correct?
>
> If you use LDP yes - if you use IP for getting to your remote PE - No.
>
> > now, how do we generate the inner label?
>
> Inner label (VPN label) is generated by BGP in any case.

..........agreed..draft kompella ppvpn i presume?


>
> > and in case we go across multiple service providers, how do we handle it
in
> > such scenarios?
> >
> > as now we would have a "outer label", an "inner label" and put the
remote
> > AS' router loopback into your IGP? how exciting!
>
> No need. If you use IP for transport of 2547 there is no outer label and
> you don't need to put your remote AS's loopacks into any IGP. Most
> implementations I know can handle mutli level recursion just fine.

........ahha i presume GRE or IP-IP kind of encap?

.......and how would you use those "nasty inner layer protocol bits" inthe
GRE header.,.why dont you just do away with them and put the MPLS Label
there?

.......and then how will you do RSVP -TE (by the way does cisco support
TED)?

.......and i mean is TED more that a "show" command ?



-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml