[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
Hi Dimitri,
See inline,
> > The second issue is how the core node identifies whether the
> > TE link configured, or discovered via LMP, is attached to
> an edge node. In
> > other words, does this need any support from LMP?
>
> since lmp allows the exchange of switching capability supported
> at the end-points (see lmp sect. 13.12.1.1), the use of method
> (described also in gmpls-routing) would deliver you links such
> that [PSC, LSC] refers to a link between a packet LSR and an OXC,
> we would then assume that this te link inter-connects an edge
> with a core node
>
Whether a TE link is able to support more than one switching capability or
not has no relation to whether a node attached to it is a core
node or edge node. A core node which supports both LSR and OXC on a TE link
could
advertise it as both PSC and TDM. In addition, for any given LSP, all TE
links
associated with the LSP must have the same switching capability. The
switching
capability is designed to faciliate the CSPF path selection for a given LSP
type (TDM, LSR, OXC, etc).
Take one example, if an edge device attached to the TDM core network
supports two
types of client signals (TDM/SONET and Ethernet over SONET via X.86 or GFP)
for a "TDM"
LSP request, then I think the TE link attached to the edge device should
advertise
the switching capability of the TE link as TDM, and then use the g-pid to
represent the client
signal for a LSP request. It will be incorrect to say that the TE link in
question is
PSC, or anything else.
Charles
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, January 15, 2003 1:19 PM
> To: Charles Chen
> Cc: 'ccamp@ops.ietf.org'
> Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
>
>
> hi charles,
>
> see in-line
>
> Charles Chen wrote:
> >
> > Is there any similar proposal of GMPLS routing support for
> the overlay
> > model?
> > There are a couple of issues that may need to be addressed.
> One is related
> > to
> > how the core node attached to one or more edge node
> advertises the TE links
> > between the edge core and the core node. In this case, for
> example, should
> > be the Link ID TLV
> > set to 0.0.0.0 or the same as the Router Address TLV,
> because there is no
> > peering router for
> > the TE link.
>
> this would then mean that you would consider such te links
> as part of the internal core domain instance
>
> > The second issue is how the core node identifies whether the
> > TE link configured, or discovered via LMP, is attached to
> an edge node. In
> > other words, does this need any support from LMP?
>
> since lmp allows the exchange of switching capability supported
> at the end-points (see lmp sect. 13.12.1.1), the use of method
> (described also in gmpls-routing) would deliver you links such
> that [PSC, LSC] refers to a link between a packet LSR and an OXC,
> we would then assume that this te link inter-connects an edge
> with a core node
>
> hope this helps,
> - dimitri.
>
> > Charles
> >
> > > -----Original Message-----
> > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > > Sent: Wednesday, January 15, 2003 4:59 AM
> > > Cc:
> > > Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > > This draft is a work item of the Common Control and
> > > Measurement Plane Working Group of the IETF.
> > >
> > > Title : GMPLS RSVP Support for the Overlay Model
> > > Author(s) : G. Swallow et al.
> > > Filename : draft-ietf-ccamp-gmpls-overlay-00.txt
> > > Pages : 10
> > > Date : 2003-1-13
> > >
> > > Generalized MPLS defines both routing and signaling
> protocols for the
> > > creation of Label Switched Paths (LSPs) in various transport
> > > technologies. These protocols can be used to support a number of
> > > deployment scenarios. This memo addresses the
> application of GMPLS
> > > to the overlay model.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ove
> > rlay-00.txt
> >
> > To remove yourself from the IETF Announcement list, send a
> message to
> > ietf-announce-request with the word unsubscribe in the body
> of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-ietf-ccamp-gmpls-overlay-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE
> /internet-drafts/draft-ietf-ccamp-gmpls-overlay-00.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before
> the "FILE"
> > command. To decode the response(s), you will need
> "munpack" or
> > a MIME-compliant mail reader. Different
> MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which
> have been split
> > up into multiple messages), so check your local
> documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
>
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone : Work: +32 3 2408491 - Home: +32 2 3434361
>