Re: MRN ext. doc

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 02 November 2008 19:08 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 A8EFD3A6B14 for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 2 Nov 2008 11:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.845
X-Spam-Level:
X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
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 aatJG2ciYSwg for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 2 Nov 2008 11:08:03 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7058E3A6B09 for <ccamp-archive@ietf.org>; Sun, 2 Nov 2008 11:08:03 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KwiF0-000AkG-LE for ccamp-data@psg.com; Sun, 02 Nov 2008 19:04:02 +0000
Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1KwiEs-000AjA-5E for ccamp@ops.ietf.org; Sun, 02 Nov 2008 19:03:58 +0000
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mA2J3mx9027248; Sun, 2 Nov 2008 19:03:48 GMT
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mA2J3lRN027234; Sun, 2 Nov 2008 19:03:47 GMT
Message-ID: <382FB452E844407982AC4889177536B7@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.be>, ccamp@ops.ietf.org
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> <00275A5B436CA441900CB10936742A38014BA566@FRVELSMBS22.ad2.ad.alcatel.com>
Subject: Re: MRN ext. doc
Date: Sun, 02 Nov 2008 19:03:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

Hello again,

>>>>>> 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.

[SNIP]

>>> 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.

[SNIP]

> 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).

I didn't actually say there was anything wrong with the document :-)
I just asked what I hoped was a simple question.

>From our discussion it looks like the answer to my question was "yes". Let's 
move on.

>>>>>> ===
>>>>>> 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.
>>>>
>>>> It doesn't make sense to use 11bbbbbb.

[SNIP]

>>> 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.

No, the Call_Attributes object is not mandatory on a Call request message 
(as currently defined). And yes, you are right, using 0bbbbbbb would not 
make it mandatory anyway.

I am *only* concerned by how the call recipient will process the Notify, how 
(if?) they will respond, and whether this will waste processing in the 
network, especially at the call recipient.

>>>>>> ===
>>>>>> 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.

[SNIP]

>>>> 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.

Weeeeell...

That use of Link Capability is not particularly clear in RFC 4974.

According to section 4.3.3. of RFC 4974 this function allows the call 
initiator to list a set of switching capablities for links that connect it 
"to the network", and for the responder to reduce the list to those 
switching capablities that it supports.

That is only half the function required.

We also need to let the call responder know that we intend using the LSP to 
support a connection in a particular client layer/region. In other words, we 
have to specify what adaptation function we want the responder to support.

It would be enough to add to the information already carried in the 
Link_Capablity object the link capability we intend to create. This could go 
in either the Link_Capablity object or in the Call_Attributes object.

Oh, by the way, Link_Capability uses a CNum of type 0bbbbbb

A