RE: MRN ext. doc
"PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be> Sun, 02 November 2008 18:31 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CEC3A67D0 for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 2 Nov 2008 10:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.471
X-Spam-Level:
X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=1.169, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, RDNS_NONE=0.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 DZeo4ZHxuh-H for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 2 Nov 2008 10:31:36 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0605F3A67AB for <ccamp-archive@ietf.org>; Sun, 2 Nov 2008 10:31:36 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KwhdZ-0006e8-0H for ccamp-data@psg.com; Sun, 02 Nov 2008 18:25:21 +0000
Received: from [62.23.212.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Dimitri.Papadimitriou@alcatel-lucent.be>) id 1KwhdG-0006c4-QM for ccamp@ops.ietf.org; Sun, 02 Nov 2008 18:25:14 +0000
Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mA2IOxAC012268; Sun, 2 Nov 2008 19:25:00 +0100
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 2 Nov 2008 19:24:59 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: MRN ext. doc
Date: Sun, 02 Nov 2008 19:24:05 +0100
Message-ID: <00275A5B436CA441900CB10936742A38014BA566@FRVELSMBS22.ad2.ad.alcatel.com>
In-Reply-To: <A0749025EAF54318A4FD2000EB1C229B@your029b8cecfe>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: MRN ext. doc
Thread-Index: Ack9D7yCOPB7Oj16RRmWxD55Lc9zfgAAXFgg
References: <00275A5B436CA441900CB10936742A380140FCD3@FRVELSMBS22.ad2.ad.alcatel.com> <8748264690F046B189E400061FE9FF7D@your029b8cecfe> <00275A5B436CA441900CB10936742A38014BA1CA@FRVELSMBS22.ad2.ad.alcatel.com> <A836E3C4314545FB913C10A1996F40C0@your029b8cecfe> <00275A5B436CA441900CB10936742A38014BA4AF@FRVELSMBS22.ad2.ad.alcatel.com> <A0749025EAF54318A4FD2000EB1C229B@your029b8cecfe>
From: PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.be>
To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
X-OriginalArrivalTime: 02 Nov 2008 18:24:59.0970 (UTC) FILETIME=[50BAD220:01C93D18]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Hi adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Sunday, November 02, 2008 6:23 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Subject: Re: MRN ext. doc > > Hi Dimitri, > > >>>> === > >>>> We will definitely (well, very probably) be asked if we can show > >>>> traceability back to the requirements. In fact, RFC 5339 > >>>> includes section > >>>> 4.1 that gives traceability from the evaluation back to the > >>>> requirements. > >>>> Section 2 of this document does not quite give the same level of > >>>> traceability such that it is necessary to read most of 5339 > >>>> to ensure that all requirements have been met. > >>> > >>> the current doc. covers the "delta" in terms of mechanism. > >>> so, do you mean that mechanisms not requiring any extensions > >>> shall also be included/described in this document ? > >> > >> Nope. > >> Simply that the I-D should explicitly call out the lacunae > >> identified in RFC 5339. > >> For example, you could say... > >> The following features are identified in [RFC5339] as > >> requiring protocol extensions: > >> 1. Feature to do something. See Section 1.2.3 of [RFC5339] > >> 2. ... > > > > ok - you would like a ref. to 5339. > > Yes. But not just a simple ref to the doc, but a ref to each of the > unanswered requirements in 5339 this is what i meant. > >>>> === > >>>> Section 4 appears to consider only the mapped server model > >>>> (allowing a many to one mapping), but not the multiplexed > >>>> server model. Is it the intention to defer this to Section 5? > >>> > >>> i don't understand the question. > >> > >> Hmm. I'm using ITU terminology. > >> > >> Mapped server has a connection set up in the server layer "on > >> demand" with only the bandwidth required by the client layer > >> connection. > >> > >> Many-to-one mapped server allows that the server connection > >> set up for a previous client layer connection may have "spare" > >> bandwidth that can be allocated ("on demand") to support a > >> further client layer connection. > >> > >> Multiplexed server model causes the "spare" bandwidth to be > >> advertised in the client layer as a link. > >> > >> My question was trying to understand how the required > >> function was split between the two sections 4 and 5. > > > > can u please use the ietf terminology at least to make the point > > understandable to me (excuse my ignorance). what is a mapped > > server ? > > OK. Well, I did try to explain in my previous response. > > In the mapped server model, a connection in used in the > server layer/region > in response to a specific demand for end-to-end connectivity > in the client > layer/region. In most cases, the server connection is created > on-demand when > the client connection request reaches the layer boundary. The client > connection is "mapped" to the server connection using the adaptation > function at the boundary node to provide continuous > end-to-end connectivity. > The server connection is not made into a link in the client > layer/region > because its purpose is only to server the current client > connection. When > the client connection is torn down, the server connection > will normally be > torn down as well. > > The many-to-one mapped server case is initiated in the same > way, but it may > be that it is actually possible to map more than one client > connection to > the server connection (effectively there is multiplexing in > the adaptation > function). However, since the server connection is not > advertised as a link > in the client layer/region, the second client connection to > be requested > behaves exactly the same except that the border node can > (before setting up > a new on-demand server connection) note that there is > available capacity on > an existing server connection and use that. > > I suppose that the mapped server cases equate to the creation > of a data link > that is not advertised (i.e. remains as a local client > layer/region link > across the server layer/region). The case where a TE link is > created and > advertised equates to the ITU's Multiplexed Server model. ok, i think i barely understood where you are heading at. now what is the issue with the doc. ? honnestly, i do not catch the point you are trying to make: section 4 addresses purely signaling procedure issue (complements existing FA triggering/selection rules) and section 5 a well-known TE problem that is how to attract traffic when no bearer is setup (it is a particular case of the generic unknown adjcacency problem). > >>>> The Call-Attributes object C-Num is picked from the 11bbbbbb > >>>> class. Why? > >>>> Surely if any node that processes the Notify message does not > >>>> understand the object, you want the Call to fail. > >>> > >>> this what has been agreed from last meeting. see Lou's preso. > >> > >> Well, it's wrong! :-) > >> > >> It doesn't make sense to use 11bbbbbb. > >> Consider that you are using a Notify message that is > >> targetted. Therefore, the first node to process the > >> Notify message is the intended end point of > >> the call, or a deliberate transit call controller. That > >> means that we require the recipient to be able to > >> process the object. > >> Furthermore, there is nowhere for the message to be > >> forwarded if the object is not understood. > > > > not sure. at the end the question is an attribute object class a > > criteria for which rejection is expected. going one step > further one can > > mandate support of the class but it is the support of the associated > > capability that matters.. one would be still blocking on the latter > > anyway if that capability would not be supported > independently of the > > object class. so it is the "mandatory or optional" nature of the > > attribute that induce support of the object not the other > way around. > > I spoke to Lou. > He had suggested 11bbbbbb because he thought the object might > end up on a > Path message. However, we don't think this would actually be the case > because the call request message is a Notify. > So he is more relaxed about this changing to 0bbbbbbb are call attributes mandatorily associated to calls (and which case one could simply mandate support of the related attribute) and their messaging/processing a must have feature of the protocol ? ... just to be clear 0bbbbbbb does not solve the former. > >> The special case of a Notify that is forwarded hop-by-hop > >> does not require that the Call-Attributes object is processed > >> since transit nodes "just forward the Notify message to the > >> target node" without looking at the contents. > >> > >> We should use 0bbbbbbb > > >>>> === > >>>> I'm puzzled that the Call described in section 5.1 does not > >>>> indicate to the intended LSP egress in which layer or > >>>> region the soon-to-be-set-up LSP will be required to > >>>> operate. > >>> > >>> because > >>> > >>> - it is the FA setup that indicates to which bearer the virtual > >>> link will be associated not the other way around > >>> > >>> - the virtual association is used by upper-region LSP so the > >>> virtual link itself is an abstraction of the bearer/network (in > >>> other terms - and by definition - one does not create Virtual > >>> TE links over Virtual TE links) > >>> > >>> the only condition which can be verified from the TEDB is > that both > >>> ends of the bearer belongs to the same LSP region (symmetry). > >> > >> I meant... > >> Suppose the head and tail of the planned virtual TE link are > >> present in three regions (or layers, don't forget layers). One > >> is the client, and two are potential servers. > >> Shouldn't the call indicate which server the caller > >> wishes/intends to use? > > > > assume a base virtual TE link [PSC,PSC] and the two link > sequence that > > can be followed by the FA-LSP are either > [PSC,LSC]..[LSC,LSC]..[LSC,PSC] > > or [PSC,TDM..[TDM,TDM]..[TDM,PSC] it is the association > between the TE > > link and LSP that determines to which FA that TE link is > now related to > > I agree completely. > And that was my point. > The call is a negotiation between end points about what > connection will be > set up, what adaptions will be applied, and what TE link will > be created. > This effectively requires the call request to state the set > of potential > adaptations, and the call response to identify the subset of > acceptable > adaptations. The connection can then be signaled in the > correct switching > type, and the resulting LSP can be associated to the TE link. per 4974, the LINK_CAPABILITY object can be used for this purpose with subobject Type 65. i did not mention it for two reasons a) it is implicit in the context (a Virtual Link by definition addresses the lowest SC value) and b) part of the procedure referenced by this doc. > >>>> === > >>>> I don't find section 3.2.1 clear on the co-existence within > >>>> the Link TLV of the IACD sub-TLV and the ISCD sub- > >>>> TLV [RFC4203]. > >>> > >>> i will add a statement IACD does not modify format/messaging and > >>> processing associated to the ISCD. > >> > >> Thanks. > >> > >> Now since there is an aggregate duplication of information > > > > where do you see the "duplication" of information b/w IACD > and ISCD ? > > Well, in the ISCD I see a list of bandwidths available per priority. > In the IACD I see a list of bandwidths available per priority. > > Clearly there is some relationship between these numbers > because they refer > to the same advertised link. > > I don't suppose that the sum of the priority 1 bandwidths for > all IACDs is > supposed to equal the advertised priority 1 bandwidth from > the ISCD. But if > the priority 1 bandwidths for one IACD was larger than that > for the ISCD it > would be strange (meaningless?). > > There is not a direct duplication of information, but there > is some overlap > of information and I am asking how it is resolved. there is no overlap of information too. the IACD is a mean to advertize adjustment capacity between two SC (so, by def. internal) that would otherwise be unknown and thus result in LSP blocking when crossing that LSR. i can give certain base rules of thumb for setting up values of IACD and its accounting (that is similar per nature to current Max LSP Bw) as part of the next revision but this is not going to prevent mis-configuration and/or misuse. -d. > A > >
- MRN ext. doc PAPADIMITRIOU Dimitri
- Re: MRN ext. doc Adrian Farrel
- RE: MRN ext. doc PAPADIMITRIOU Dimitri
- Re: MRN ext. doc Adrian Farrel
- RE: MRN ext. doc PAPADIMITRIOU Dimitri
- Re: MRN ext. doc Adrian Farrel
- RE: MRN ext. doc PAPADIMITRIOU Dimitri
- Re: MRN ext. doc Adrian Farrel