[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-00.txt
hi see-line...
Charles Chen wrote:
>
> 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.
i think you took this as a "rule" why i have responded
to a potential way to deliver this - i know that this
may become an issue if multiple switching capabilities
are supported => what you have to do is to select what
you'd support for your edge node requests (the only
complexity i see is when the client support more than
one of these switching capabilities)
> In addition, for any given LSP, all TE
> links
> associated with the LSP must have the same switching capability.
from a signalling viewpoint it is today clearly indicated
that "Indicates the type of switching that should be performed
on a particular link. This field is needed for links that
advertise more than one type of switching capability." i
don't know how you have inferred the above rule from this
- also the lsp hierarchy drafts explains how to cross an
lsp region in all its details (see section 7.1) in a sense
what described in this document is how to emulate overlays
thus the methods proposed there should be fine tunable in
the context you describe here above
> The
> switching
> capability is designed to faciliate the CSPF path selection for a given LSP
> type (TDM, LSR, OXC, etc).
your te link infers its own switching capability from the
above thus it will become psc capable or whatever the
edge node supports, it seems you took my example as a rule
> 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.
once again you should read the above as an example (refer
to gmpls-routing for more combinations - i refer you to the
section 4.4.7 of gmpls-routing)
thanks,
- dimitri
Charles Chen wrote:
>
> 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
> >
--
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