[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-kawakami-mpls-lsp-vlan-00.txt
all,
would like to add something here in the context
of this i-d, the following RFC
http://www.ietf.org/rfc/rfc3468.txt
aka "The Multiprotocol Label Switching (MPLS) Working
Group decision on MPLS signaling protocols" clearly
states that "the MPLS working group consensus to not
undertake any new work related to RFC 3212 [RFC3212],"
(aka "CR-LDP"), see also Section 6 of this RFC 3468
thus i am bit surprised this i-d proposes the use
of cr-ldp, for instance:
" Control plane:
The VLAN-LSP setting and management is done in the control plane by
the control component of VLAN-LSR. The VLAN-LSP setting can be
achieved in two ways: explicit path for traffic engineering, (using
Constraint-based Routing LDP, CR-LDP) [...]"
or
" The edge VLAN-LSR uses CR-LDP signalling protocol to send Label
Request Message to the VLAN-LSR having the next IP address in the
Explicit Route TLV (ER-TLV)."
would it possible to "review" this i-d wrt to the wg
consensus otherwise i don't see how this i-d can gain
the consensus of the above mentioned working group ?
thanks,
- dimitri.
Dimitri.Papadimitriou@alcatel.be wrote:
>
> hi,
>
> per gmpls, Layer-2 Switch Capable (L2SC) interfaces are
> defined:
>
> Interfaces that recognize frame/cell boundaries and can forward data
> based on the content of the frame/cell header. Examples include
> interfaces on Ethernet bridges that forward data based on the
> content of the MAC header and interfaces on ATM-LSRs that forward
> data based on the ATM VPI/VCI.
>
> i agree with juergen, this i-d should be discussed at
> the ccamp working group
>
> thanks,
> - dimitri.
>
> Genadi Velev wrote:
> >
> > Hi Juergen,
> >
> > thanks for the feedback! This was (and seems to be still) a hot topic. The
> > decision where to present the draft has been already a subject of
> > discussions with the chairmen of MPLS, PWE3 and PPVPN WGs. The reason to let
> > this draft for submission in the MPLS WG was that the basic intention is to
> > propose a new LDP extension ("VLAN label TLV") and MPLS WG is in charge of
> > the LDP protocol.
> >
> > It's true that the transport plane in our proposal is based on VLAN-aware
> > Ethernet switches. Compared to the GMPLS classification of interfaces
> > (RFC3471), VLAN tag switching belongs (I'd say so) to the Packet-Switch
> > Capable (PSC) interfaces, and thus, extensions regarding these interfaces
> > should be a subject of the MPLS WG.
> >
> > This is my personal opinion. However, since I'm not a long-experienced
> > person in the IETF's MPLS related work, I'd like to hear also another
> > opinions on this issue.
> >
> > regards,
> > Genadi
> >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Heiles
> > > Juergen
> > > Sent: Friday, February 28, 2003 12:17 PM
> > > To: 'velev@panasonic.de'; mpls@UU.NET; ccamp@ops.ietf.org
> > > Cc: vlan-mpls@panasonic.de
> > > Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt
> > >
> > >
> > > Genadi,
> > >
> > > the draft proposes to use the MPLS control plane protocols for a
> > > different transport plane (Ethernet VLAN).
> > > This is excatly what GMPLS is about. So I think it would be
> > > better to have the ID and dicussion in ccamp under the GMPLS work.
> > >
> > > Regards
> > >
> > > Juergen
> > >
> > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Genadi Velev [mailto:velev@panasonic.de]
> > > > Gesendet: Donnerstag, 27. Februar 2003 17:53
> > > > An: mpls@UU.NET
> > > > Cc: vlan-mpls@panasonic.de
> > > > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt
> > > >
> > > >
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > > >
> > > > Hi all,
> > > >
> > > > A new draft was published today (please see below).
> > > >
> > > > Any feedback and comments are welcome, especially from those
> > > > of you who are
> > > > dealing with packet transport over wide area Ethernet networks.
> > > >
> > > > thanks,
> > > > Genadi
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> > > > > Internet-Drafts@ietf.org
> > > > > Sent: Thursday, February 27, 2003 1:44 PM
> > > > > To: IETF-Announce:
> > > > > Cc: mpls@UU.NET
> > > > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt
> > > > >
> > > > >
> > > > > A New Internet-Draft is available from the on-line
> > > > > Internet-Drafts directories.
> > > > >
> > > > >
> > > > > Title : Method to Setup LSP using VLAN Tag Switching
> > > > > Author(s) : T. Kawakami et al.
> > > > > Filename : draft-kawakami-mpls-lsp-vlan-00.txt
> > > > > Pages : 15
> > > > > Date : 2003-2-26
> > > > >
> > > > > This document describes a method to setup a Layer 2 tunnel over
> > > > > networks based on Ethernet technology. For this purpose,
> > > > the ports of
> > > > > an Ethernet switch are configured to forward VLAN
> > > > tag-labeled packets
> > > > > incoming from a certain port to another unambiguous port by using
> > > > > VLAN tag information. The Ethernet switches themselves are a part of
> > > > > the Label Switching Routers (LSRs), which distribute the VLAN tags
> > > > > using Label Distribution Protocol (LDP). To enable LDP to
> > > > fulfil this
> > > > > function, an LDP extension is proposed. The introduced method
> > > > > simplifies the transport of Ethernet frames over wide area Ethernet
> > > > > networks.
> > > > >
> > > > > A URL for this Internet-Draft is:
> > > > >
> > > http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-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-kawakami-mpls-lsp-vlan-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-kawakami-mpls-lsp-vlan-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 : +32 3 240-8491
--
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 : +32 3 240-8491