Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt

From: [email-masked]
Date: Sun, 02 Mar 2003 15:53:49 +0100

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.

[email-masked] 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: [email-masked] [mailto:[email-masked]]On Behalf Of Heiles
> > > Juergen
> > > Sent: Friday, February 28, 2003 12:17 PM
> > > To: [email-masked]'; [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > > Gesendet: Donnerstag, 27. Februar 2003 17:53
> > > > An: [email-masked]
> > > > Cc: [email-masked]
> > > > 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: [email-masked] [mailto:[email-masked]]On Behalf Of
> > > > > [email-masked]
> > > > > Sent: Thursday, February 27, 2003 1:44 PM
> > > > > To: IETF-Announce:
> > > > > Cc: [email-masked]
> > > > > 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:
> > > >     [email-masked].
> > > > 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 : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 2 Mar 2003 09:16:29 -0800 (PST)

Hi All,

One high-level comment, and one addressing the issue that Dimitri
raised;

The CCAMP WG deals (mostly) with protocol extensions that are *common*
across a variety of technologies, such as GMPLS signaling and routing,
and LMP.  There are cases of doing specific technology work, such as
SDH, only because there is no WG for that work.  The WG chairs would
have to consult with their ADs to figure out the right home for this
work that seems to me to be specific.

> thus i am bit surprised this i-d proposes the use

Any i-d can propose anything :-)  If it is to be a WG doc, then
the CR-LDP parts will have to be reviewed.  If it is to be Standards
Track, the CR-LDP parts will have to be removed -- if they stay in,
the doc will at best be put on Info track.

Kireeti.

---

From: Genadi Velev <[email-masked]>
Date: Mon, 03 Mar 2003 14:56:38 +0100

Hi all,

as I can see, 2 different issues raised regarding this draft. (please see
inline...)

1) proper WG for this draft

> work that seems to me to be specific.
Kireeti,
thanks for your clarification. You are right that this technology is a
specific one, but OTOH as Dimitri pointed out it fits perfectly to the group
of Layer-2 Switch Capable (L2SC) interfaces.
I would like to ask you and Loa/George to help us to find the proper WG for
the draft!

2) employment of CR-LDP

> the doc will at best be put on Info track.
Kireeti and Dimitri,
I didn't know about the existence of MPLS WG's consensus and RFC 3468. Now,
after your valuable comments, I realize that we - the authors of the ID -
should reconsider the employment of CR-LDP. Since 2 protocols are proposed
to setup LSP (LDP and CR-LDP), it would be possible in a future version of
the ID to specify the use of LDP only.

Our initial intention of the ID was, if the ID is accepted as WG doc, that
it can become an informational RFC, not a standard one.

thanks,
Genadi

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 3 Mar 2003 13:55:49 -0800 (PST)

Hi Ganadi,

> of Layer-2 Switch Capable (L2SC) interfaces.

I agree that this applies to L2SC interfaces.  But CCAMP doesn't deal
with L2SC interfaces (it's not in the charter).

> I would like to ask you and Loa/George to help us to find the proper WG for

We'll talk to the ADs and let you know.

I understand that this may not be the answer you want; however,  In the
end, the IESG/IAB must decide what work items a particular WG can work
on.  Here, you are in the unfortunate position that there is no WG that
is chartered to do this work.

If you are going for an Informational document, things may be a bit
easier.

Kireeti.