Re: [mpls-tp] [mpls] R: Use of term "interface" in MPLS-TP Identifiers and OAM Framework drafts
Greg Mirsky <gregimirsky@gmail.com> Fri, 10 December 2010 18:31 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 9028228C100; Fri, 10 Dec 2010 10:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.071
X-Spam-Level:
X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=0.527,
BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJDZKSC80AO9;
Fri, 10 Dec 2010 10:31:18 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com
[209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 5512F28B56A;
Fri, 10 Dec 2010 10:31:18 -0800 (PST)
Received: by qyk34 with SMTP id 34so1138862qyk.10 for <multiple recipients>;
Fri, 10 Dec 2010 10:32:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:received:in-reply-to
:references:date:message-id:subject:from:to:cc:content-type;
bh=hN/DYRtjP3JzKJ9/4cBuHKwzvDPrs+q8lQI3s8fB+Yw=;
b=q0aIWeIbFTERh6BscsR08pFL66oNpKsZtYigFXNTn7zsyv2cLjH7QBk1sZzYRTDgOZ
w+IQao6t/vimdsMwN3VEwroPjVyZXWhVmqN0TrOhTt27VJfOfoxLY+PLCsU1OcQNZa9x
E0QGxQb+X/XBRXQXk4k7fGKpVKnmPiw7tRUGU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
b=HmLOvxKjUfvqpJtVgxDQrq6OR0EzyXUAp5afuluaYXRsNOTHZREDlKsvIaIXu6EPub
zo7ZcZry1jZThNKXc1AYYNcK4BmqWXSBEBUNB3LaoACSL+MVzGtrUyb2+sGfUS2R71nD
Y321yMWwlBKHysx51V6Amz1dFbAdBOfZwERMk=
MIME-Version: 1.0
Received: by 10.224.28.147 with SMTP id m19mr1001039qac.255.1292005969946;
Fri, 10 Dec 2010 10:32:49 -0800 (PST)
Received: by 10.220.187.6 with HTTP; Fri, 10 Dec 2010 10:32:49 -0800 (PST)
In-Reply-To: <A3C5DF08D38B6049839A6F553B331C76D6B83362C8@ILPTMAIL02.ecitele.com>
References: <AANLkTikBNsFZ=g-rQdPu9avPAoUdsNaiD==dxoRC6fq7@mail.gmail.com>
<15740615FC9674499FBCE797B011623F16CD17E1@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
<A3C5DF08D38B6049839A6F553B331C76D6B78ED566@ILPTMAIL02.ecitele.com>
<15740615FC9674499FBCE797B011623F16D36BEA@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
<007201cb9875$5f1ddfa0$1d599ee0$@olddog.co.uk>
<A3C5DF08D38B6049839A6F553B331C76D6B83362C8@ILPTMAIL02.ecitele.com>
Date: Fri, 10 Dec 2010 10:32:49 -0800
Message-ID: <AANLkTikUZ3ETHU7zdEVKR3Y-BALGDMri_YQfatzrJ7j_@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Content-Type: multipart/alternative; boundary=0015175cb07ce2ea3104971294db
Cc: "mpls-tp@ietf.org" <mpls-tp@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls-tp] [mpls] R: Use of term "interface" in MPLS-TP
Identifiers and OAM Framework drafts
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2010 18:31:20 -0000
Dear Sasha and All, I agree with you that re-defining "interface" will confuse things more than it will clarify. I think that it will be helpful to record implied interpretation of "MPLS interface" in Rosetta Stone. In documents where use of "interface" is ambiguous we can use, as much as possible, other terms. It might be perhaps "virtual interface" or another term as well recorded in the Rosetta Stone I-D. Regards, Greg On Fri, Dec 10, 2010 at 9:34 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Adrian, > I agree with you that "interface" has a long history in the IETF and is not > always used consistently. > > My concern is about the term "per-interface label space" as it appears in > 3031 and the consequent IETF documents. > > Does your email imply that, from your point of view, per-interface label > space includes label space per terminated tunnel? > And that, as a consequence, processing of an incoming downstream-allocated > label may depend on the label (or labels) that have been present in the > label stack above it and have been popped? > > I'd like to quote from Section 3.9 of RFC 3031 just to make sure we are all > on the same page: > > Although, as we shall see, MPLS supports a hierarchy, the processing > of a labeled packet is completely independent of the level of > hierarchy. The processing is always based on the top label, without > regard for the possibility that some number of other labels may have > been "above it" in the past, or that some number of other labels may > be below it at present. > > Regards, > Sasha > > ________________________________________ > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of > Adrian Farrel [adrian@olddog.co.uk] > Sent: Friday, December 10, 2010 4:20 PM > To: mpls-tp@ietf.org; mpls@ietf.org > Subject: Re: [mpls-tp] [mpls] R: Use of term "interface" in MPLS-TP > Identifiers and OAM Framework drafts > > I agree with Italo (try not to gasp so loudly :-) > > The I-Ds do appear to use the term consistently, and bringing this > important > term to the front so it is really noticed seems important. Also adding it > to the > Rosetta Stone I-D in a consistent way. > > A *separate* issue is determining whether we are happy with the definition > being > used. "interface" is a wriggly term with a long history in the IETF. Those > wanting to pick up some background could do worse than read IF-MIB > (RFC2863) and > then look at the information about the use of "interfaces" in Section 8 of > RFC > 3813. > > In RFC 4397 we worked with experts in ITU-T SG15 and got a bit anal about > the > definitions. Section 3.6 discusses "link interfaces", and it would be nice > to > stay consistent. > > The question of "layers" is delicate, and should probably include > "sub-layers". > But note that the interface is not the layer (which seems to be what Sasha > is > objecting to), it is the "gateway" to the layer. One might think of it in > terms > of adaptation functions, and indeed, I think this *is* consistent with the > current MPLS data plane architecture. Consider, for example, that an LSP > end may > be represented as a virtual interface (i.e. the LSP is a virtual link). > > Cheers, > Adrian > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > BUSI, ITALO (ITALO) > > Sent: 10 December 2010 12:07 > > To: Alexander Vainshtein; mpls-tp@ietf.org; mpls@ietf.org > > Subject: [mpls] R: [mpls-tp] Use of term "interface" in MPLS-TP > Identifiers > and > > OAM Framework drafts > > > > Sasha, > > > > The OAM Framework and Identifier drafts are already using the term > "interface" > > in a consistent way among each other. > > > > According to the Identifiers draft the attachment point to a server > MPLS-TP > > Tunnel is an interface. > > > > The change #2 I am proposing is just aimed at clarifying that the server > MPLS-TP > > tunnel is a server sub-layer and not a server layer as per past > discussion. > > > > Italo > > > > > -----Messaggio originale----- > > > Da: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > > Inviato: venerdì 10 dicembre 2010 10.48 > > > A: BUSI, ITALO (ITALO); mpls-tp@ietf.org; mpls@ietf.org > > > Oggetto: RE: [mpls-tp] Use of term "interface" in MPLS-TP Identifiers > and > > > OAM Framework drafts > > > > > > Italo, > > > Lots of thanks for a prompt response. > > > I agree that different MPLS-TP documents treat the term "interface" > > > differently, and this adds to the overall havoc. > > > > > > I strongly object to treating sub-layers as interfaces in MPLS-TP > because > > > IMO this would break the MPLS data plane in an irreparable manner. > > > > > > As a consequence I suggest we keep the definition used in the MPLS-TP > > > Identifiers draft and rework the OAM framework document accordingly. > > > > > > Regards, > > > Sasha > > > > > > > > > > > > From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of > > > BUSI, ITALO (ITALO) [italo.busi@alcatel-lucent.com] > > > Sent: Friday, December 10, 2010 11:00 AM > > > To: mpls-tp@ietf.org; mpls@ietf.org > > > Subject: [mpls-tp] Use of term "interface" in MPLS-TP Identifiers and > OAM > > > Framework drafts > > > > > > > > > I see a lot of comments related to the term "interface" used within the > > > OAM Framework draft in the context of the per-interface MIP definition > and > > > NO comments on the same term used within the Identifiers draft. > > > > > > I would like to clarify that the same term "interface" actually > represents > > > the same concept in both the MPLS-TP Identifiers and MPLS-TP OAM > > Framework > > > drafts. > > > > > > I would therefore propose that the following definition is added to > both > > > drafts: > > > > > > " > > > Interface: An interface is the attachment point to a server (sub-)layer > > > e.g., MPLS-TP section or MPLS-TP tunnel. > > > " > > > > > > This definition is taken from the text in section 4 of the Identifiers > > > draft with the following proposed changes: > > > > > > 1) c/Access Point (AP)/attachment point/ as proposed by ITU-T > > > > > > 2) c/layer/(sub-)layer/ to align the definition with the outcome of > past > > > discussion: label stacking is a form of sub-layering with the MPLS and > > > MPLS-TP layer network. > > > > > > I have a strong opinion that both the MPLS-TP Identifiers and the > MPLS-TP > > > OAM Framework must use the same term (and definition) to identify the > same > > > entity. > > > > > > I have a preference to keep the term "interface" on both drafts to > speed > > > up the work. > > > > > > Italo > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >
- [mpls-tp] Looking for alternative term for per-in… Greg Mirsky
- [mpls-tp] 答复: Looking for alternative term for pe… wei.hongbo
- Re: [mpls-tp] 答复: Looking for alternative term fo… Alexander Vainshtein
- Re: [mpls-tp] Looking for alternative term for pe… wei.hongbo
- [mpls-tp] Use of term "interface" in MPLS-TP Iden… BUSI, ITALO (ITALO)
- Re: [mpls-tp] Use of term "interface" in MPLS-TP … Alexander Vainshtein
- [mpls-tp] R: Use of term "interface" in MPLS-TP I… BUSI, ITALO (ITALO)
- Re: [mpls-tp] [mpls] R: Use of term "interface" i… Adrian Farrel
- [mpls-tp] RE: 答复: Looking for alternative term fo… maarten vissers
- Re: [mpls-tp] [mpls] R: Use of term "interface" i… Alexander Vainshtein
- Re: [mpls-tp] [mpls] R: Use of term "interface" i… Greg Mirsky
- Re: [mpls-tp] [mpls] R: Use of term "interface" i… Adrian Farrel