From karagian@cs.utwente.nl Sat Mar 9 01:42:03 2013 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2821F84BB; Sat, 9 Mar 2013 01:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLfaAyWh+2ni; Sat, 9 Mar 2013 01:42:01 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 47C0221F8415; Sat, 9 Mar 2013 01:41:59 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sat, 9 Mar 2013 10:42:53 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.16]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Sat, 9 Mar 2013 10:41:57 +0100 From: To: , Thread-Topic: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 Thread-Index: AQHNwzIz0DiUx9R5AUqjyGs4URlrFZidzamOgAAAn5k= Date: Sat, 9 Mar 2013 09:41:56 +0000 Message-ID: References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> , <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> In-Reply-To: <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE10EXMBX23adutwent_" MIME-Version: 1.0 Cc: pcn@ietf.org, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 09:42:03 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE10EXMBX23adutwent_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks for your comments! Before answering to your comments I would like to emphasize that I strongly= agree with the analysis done by Francois in the following email (with an a= dditional email sent by me) on the two options of accomplishing RSVP over P= CN signaling support: http://www.ietf.org/mail-archive/web/tsvwg/current/msg11601.html http://www.ietf.org/mail-archive/web/tsvwg/current/msg11602.html In addition to that, we agree with the proposal of Francois of choosing opt= ion (A) since the RFC4860 operations has been thought through and there ha= s been some implementation of RSVP Aggregation, so we have some confidence = that the solution can deal with the more challenging situations (rerouting = in core, failure of an ingress edge, failure of an egress edge, rerouting t= owards a different edge,=85). Therefore, we have used the argumentation provided by Francois in Section 1= .2 of (new draft version) draft-ietf-tsvwg-rsvp-pcn-04 to justify why RFC48= 60 should be used to accomplish the RSVP over PCN signaling support. After mentioning the above I will try to answer your comments below, in lin= e! > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: donderdag 15 november 2012 14:08 > To: Karagiannis, G. (EWI); anuragb@cisco.com > Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardle= y@bt.com; > PCN IETF list; rsvp-dir@ietfa.amsl.com > Subject: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 > Georgios, Anurag, > Below is the main point of my review, arguing that aggregate reservations > are redundant. I'm reviewing as: > - a member of the RSVP directorate > - one of the early PCN design team > - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is bas= ed. > I would have missed any decision to use aggregate reservations. > Pls point me to the relevant discussion (e.g. Subject line / date). > I admit I tuned out of much of the later PCN signalling discussion. > I found the whole exercise of abstracting PCN away from specific signalli= ng > protocols highly tedious; it meant we couldn't sensibly address important > issues like message reliability, timeliness etc. > Nonetheless, here's why I believe RSVP aggregation is redundant: > PCN edge-nodes support the concept of an ingress-egress aggregate in thei= r > own internal tables, but they don't need to refer to an aggregate on the > wire{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which > e2e reservations belong to which aggregate by grouping together those > e2e reservations with the same next hop or previous hop respectively. Georgios: This is an additional functionality that needs to be supported by= the PCN-ingress-nodes and PCN-egress-nodes. This is already provided by RF= C 4860. Please see the argumentation given above of why we should choose RF= C 4860 instead of defining a new solution. > {Note 1: except in one case described later - but it doesn't require > all the other baggage of aggregate reservations} Georgios: New aggregation related features are required. These aggregation = related features are provided by RFC 4860. Please see the argumentation gi= ven above why we should choose RFC 4860 instead of defining a new solution. =3D=3DBackground=3D=3D > Aggregate reservations [RFC3175, RFC4860] are designed to reduce the > state required on interior nodes. Interior nodes still require state > per aggregate reservation, but only reservation state, not classification > and scheduling state [RFC3175, Section 1.4.1 last para]. Georgios: This is only one of the goals of using RFC3175, RFC4860, the othe= r one is to aggregate and provide all the required protocol operations to a= chieve the aggregation of e2e RSVP flows/states into RSVP aggregated flows/= states. The latter needs to also be accomplished within the PCN context, w= here the states associated to the e2e flows need to be matched to the Ingre= ss-Egress-Aggregate state. Therefore in the PCN context it is needed to add= the required protocol operation at PCN edge nodes to achieve this. These a= dditional aggregation based protocol operations are already provided by RFC= 4860. Please see the argumentation given above of why we should choose RF= C 4860 instead of defining a new solution for this purpose. >I n contrast, as you correctly point out (in Section 2.1.7), PCN requires > absolutely no reservation-related state on interior nodes. Georgios: Agree with the above. This can be accomplished, see (new draft ve= rsion) draft-ietf-tsvwg-rsvp-pcn-04, by configuring the PCN-interior-nodes = to distinguish neither RSVP generic aggregated sessions and their associate= d messages [RFC4860], nor e2e RSVP sessions and their associated messages [= RFC2205]. > =3D=3DDisadvantages=3D=3D > Requiring PCN to use aggregate reservations has the following three > disadvantages and no advantages: > 1) Redundant Processing > The PATH message between aggregator and deaggregator in rsvp-pcn-03 > (triggered by an E2E PathErr message from deaggregator to aggregator) > is redundant, and just doubles the processing required at the PCN-edge-no= des > (if this isn't obvious, I spell it out separately for PATH & RESV message= s below). Georgios: The load and processing of the Aggregated PATH and Aggregated RES= V messages compared to the processing of the total load and processing of e= 2e RSVP messages is to be neglected. > 2) Reduced Resilience > Not only is an aggregate PATH redundant, it actually reduces resilience. > Because an aggregate PATH is pinned to interior routers. Therefore, when > routing changes, it is more complex and slower to move to the new route. > By not pinning to interior routers, PCN was designed to 'just work' over > interior routing changes - with no need for any changes to the RSVP PATHs= . > (But it would still detect overload after a re-route and terminate or > rate-reduce flows if necessary.) Georgios: I agree with Francois, when saying that the drawbacks pointed out= by Bob are probably not as serious as Bob suggested, given that the Aggreg= ated RSVP signaling would be ignored by interior nodes. In particular, we d= on't see why aggregate RSVP signaling would impact rerouting inside the PCN= core since packets from individual sessions would be routed independently = of the reservation. > 3) Extra Latency > A further disadvantage is the extra latency required for the first reserv= ation > that sets up an aggregate. This is two ingress-egress round trips minus t= he > round trip time from egress to destination (or one ingress-egress round t= rip > if it is greater). This will rarely add to latency on heavily used > ingress-egress aggregates, but it will occur frequently on all the > 'long-tail' (lightly used) ingress-egress aggregates. Georgios: This is only required for the first reservation that sets up an a= ggregate, which will not occur often. This means that this extra latency is= to be neglected. > =3D=3DPATH=3D=3D > With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PA= TH > messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator cha= nges > them back to RSVP before forwarding onward. Also the aggregator sends an > aggregate PATH message, which is processed by each interior node and by > the deaggregator. > On a path across a PCN region, given interior nodes ignore aggregate > PATH messages as well, the only PCN nodes that handle aggregate messages > are the aggregator and the deaggregator. The aggregator and deaggregator > process all the e2e PATH messages anyway, so if we require the aggregator > to add up all the e2e PATH messages and form them into an aggregate PATH > message, this is just extra redundant work for both PCN-edge-nodes. Georgios: But also in the PCN context it is needed to maintain information = about which e2e flows are associated with a Ingress-Egress-Aggregate, such = that when a severe congestion occurs the ingress could release the accurate= number of the selected e2e flows that are associated with the same Ingress= -Egress-Aggregate. So an additional protocol operation has to be specified and implemented in = the PCN edge nodes to maintain this association between e2e flows and the I= ngress-Egress-Aggregate states. These additional aggregation based protocol= operations are already provided by RFC 4860. Please see the argumentation= given above of why we should choose RFC 4860 instead of defining a new sol= ution for this purpose. > =3D=3DRESV=3D=3D > The deaggregator unicasts e2e RESV messages to the previous RSVP hop, > which is the aggregator. Therefore, if we require the deaggregator > to add up all the RESV messages and form them into an aggregate > RESV message, this is just redundant work for both PCN-edge-nodes, > because they both already process all the e2e RESV messages anyway, > and no other node uses the aggregate RESV messages. Georgios: The answer given above related to the Aggregated PATH message hol= ds also for the Aggregated RESV message. > =3D=3DPCN object=3D=3D > This raises the question of how the PCN-egress communicates the > various marking rates (the PCN object) to the PCN-ingress. There > are two possibilities: > i) the PCN-egress includes a current PCN object in each e2e RESV > that it returns to the PCN-ingress. The PCN-ingress strips the > PCN object out before forwarding the RESV back to the previous > RSVP hop. > ii) the PCN-egress attaches a PCN object to an aggregate reservation, > as in pcn-rsvp-03. > Either are possible, because a PCN object carries information about marki= ng > probabilities, and PCN works on the assumption that the marking probabili= ty > of an ingress-egress aggregate is the same as the marking probability of > the flows within the aggregate. A PCN object can be contained either > in an e2e RESV or an aggregate RESV as long as the PCN-ingress can > associate an e2e RESV with the correct aggregate (which it can, because > it maintains an internal table of mappings between e2e reservations > and their aggregates). > Which of the two is best is a question of message timing... > * For e2e admission decisions, the PCN object is only needed at the time > each e2e RESV is sent, so option i) makes sense. > * For flow rate reduction or flow termination decisions, the deaggregator > needs to regularly send PCN objects to the ingress. > The PCN-egress is sending regular e2e RESV refresh messages to the PCN-in= gress, > so a PCN object can be included in each of these. To ensure that PCN obje= cts > are sent often enough, I suggest the PCN-egress also maintains a timer p= er > ingress-egress aggregate which it resets every time it sends a PCN object > for that IEA. If the timer expires, the PCN-egress sends a PCN object > to the PCN-egress even thought it was not triggered by an e2e RESV refres= h. > We could require the SESSION object in this message to refer to either of= : > a) any one of the e2e SESSIONs in the aggregate, > b) the aggregate. > In case (a), the message would need to somehow tell the ingress not to fo= rward > this RESV refresh to the RSVP previous hop. > In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and > aggregate SESSIONs, it would include an entry for the aggregate that maps > to itself. If the result of the look-up is the same as the input, it know= s > not to forward the RESV refresh further. > The wire protocol doesn't need to identify whether the SESSION is an aggr= egate > or not. This is the one case I mentioned at the start {Note 1} where an a= ggregate > is referred to on the wire. Georgios: I do not agree, using e2e RESV to carry the PCN object has severe= drawbacks. In particular, what happens in the situation where there is a change of rou= te for a given e2e RSVP reservation/session (i.e. changing its PCN-ingress-= node and/or PCN-egress-node) right when the PCN-egress-node decides to use= a e2e RSVP signalling message (associated with this e2e RSVP session) to n= otify the aggregate PCN information (PCN admission control and/or flow term= ination information) to the PCN-ingress-node? In this situation it is possible that the aggregated PCN information (the P= CN object) will not be received by the right PCN-ingress-node, having as im= plication that the congestion in the PCN domain will not be solved accurate= ly and in time! This problem cannot occur when an Aggregated RESV message is used to carry = the PCN object. > In summary, PCN already reduces reservation state and processing to nothi= ng > on interior nodes. Adding aggregate reservations to PCN requires more pro= cessing > and state, it unnecessarily pins routes to interior nodes and adds unnece= ssary latency. Georgios: As I already mentioned above, we agree with the proposal of Franc= ois of choosing option (A) since the RFC4860 operations has been thought t= hrough and there has been some implementation of RSVP Aggregation, so we ha= ve some confidence that the solution can deal with the more challenging sit= uations (rerouting in core, failure of an ingress edge, failure of an egres= s edge, rerouting towards a different edge,=85). Therefore, we have used the argumentation provided by Francois in Section 1= .2 of (new draft version) draft-ietf-tsvwg-rsvp-pcn-04 to justify why RFC48= 60 should be used to accomplish the RSVP over PCN signaling support. Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE10EXMBX23adutwent_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5D3259ABF0B91B4890E35371E7CF4EDC@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable

Hi  Bob,

 

Thanks for your comments!<= /font>

 

Before answering to your c= omments I would like to emphasize that I strongly agree with the analysis d= one by Francois in the following email (with an additional email sent by me) on the two options of accomplishing RSVP o= ver PCN signaling support:

 

http://www.ietf.org/mail-archive/web/tsvwg/current/msg11601.htm= l

http://www.ietf.org/mail-archive/web/tsvwg/current/msg11602.htm= l

 

In addition to that, we ag= ree with the proposal of Francois of choosing option (A)  since the RF= C4860 operations has been thought through and there has been some implement= ation of RSVP Aggregation, so we have some confidence that the solution can deal with the more challenging situa= tions (rerouting in core, failure of an ingress edge, failure of an egress = edge, rerouting towards a different edge,=85).

 

<= span lang=3D"EN-US">Therefore, we have used the argumentat= ion provided by Francois in Section 1.2 of (new draft version) draft-ietf-t= svwg-rsvp-pcn-04 to justify why RFC4860 should be used to accomplish the RSVP over PCN signaling support.

 

After mentioning the above= I will try to answer your comments below, in line!

 

 

 

> From: Bob Briscoe [ma= ilto:bob.briscoe@bt.com]

>  Sent: donderdag 15 november 2012 14:08

> To: Karagiannis, G. (= EWI); anuragb@cisco.com

> Cc: carlberg@g11.org.= uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardley@bt.com;

> PCN IETF list; rsvp-d= ir@ietfa.amsl.com

> Subject: Redundant ag= gregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

> Georgios, Anurag,

 

> Below is the main poi= nt of my review, arguing that aggregate reservations

> are redundant. I'm re= viewing as:

> - a member of the RSV= P directorate

> - one of the early PC= N design team

> - a co-author of draf= t-lefaucheur-rsvp-ecn-01, on which this draft is based.

 

> I would have missed a= ny decision to use aggregate reservations.

> Pls point me to the r= elevant discussion (e.g. Subject line / date).

 

> I admit I tuned out o= f much of the later PCN signalling discussion.

> I found the whole exe= rcise of abstracting PCN away from specific signalling

> protocols highly tedi= ous; it meant we couldn't sensibly address important

> issues like message r= eliability, timeliness etc.

 

> Nonetheless, here's w= hy I believe RSVP aggregation is redundant:

 

> PCN edge-nodes suppor= t the concept of an ingress-egress aggregate in their

> own internal tables, = but they don't need to refer to an aggregate on the

> wire{Note 1}. PCN-ing= ress and PCN-egress nodes intrinscially know which

> e2e reservations belo= ng to which aggregate by grouping together those

> e2e reservations with= the same next hop or previous hop respectively.

 

Georgios: This is an addit= ional functionality that needs to be supported by the PCN-ingress-nodes and= PCN-egress-nodes. This is already provided by RFC 4860. Please see the argumentation given above of why we should cho= ose RFC 4860 instead of defining a new solution.

 

> {Note 1: except in on= e case described later - but it doesn't require

> all the other baggage= of aggregate reservations}

 

Georgios: New aggregation = related features are required. These aggregation related features are provi= ded by RFC 4860.  Please see the argumentation= given above why we should choose RFC 4860 instead of defining a new soluti= on.

 

 

=3D=3DBackground=3D=3D

> Aggregate reservation= s [RFC3175, RFC4860] are designed to reduce the

> state required on int= erior nodes. Interior nodes still require state

> per aggregate reserva= tion, but only reservation state, not classification

> and scheduling state = [RFC3175, Section 1.4.1 last para].

 

Georgios: This is only one= of the goals of using RFC3175, RFC4860, the other one is to aggregate and = provide all the required protocol operations to achieve the aggregation of e2e RSVP flows/states into RSVP aggregated f= lows/states.  The latter needs to also be = accomplished within the PCN context, where the states associated to the e2e= flows need to be matched to the Ingress-Egress-Aggregate state. Therefore = in the PCN context it is needed to add the required protocol operation at PCN edge nodes to achieve this. These a= dditional aggregation based protocol operations are already provided by RFC= 4860.  Please see the argumentation= given above of why we should choose RFC 4860 instead of defining a new sol= ution for this purpose.

 

 

>I n contrast, as you c= orrectly point out (in Section 2.1.7), PCN requires

> absolutely no reserva= tion-related state on interior nodes.

 

Georgios: Agree with the a= bove. This can be accomplished, see (new draft version) draft-ietf-tsvwg-rs= vp-pcn-04, by configuring the PCN-interior-nodes to distinguish neither RSVP generic aggregated sessions and their associat= ed messages [RFC4860], nor e2e RSVP sessions and their associated messages = [RFC2205].

 

 

> =3D=3DDisadvantages= =3D=3D

> Requiring PCN to use = aggregate reservations has the following three

> disadvantages and no = advantages:

 

> 1) Redundant Processi= ng

> The PATH message betw= een aggregator and deaggregator in rsvp-pcn-03

> (triggered by an E2E = PathErr message from deaggregator to aggregator)

> is redundant, and jus= t doubles the processing required at the PCN-edge-nodes

> (if this isn't obviou= s, I spell it out separately for PATH & RESV messages below).

 

Georgios: The load and pro= cessing of the Aggregated PATH and Aggregated RESV messages compared to the= processing of the total load and processing of e2e RSVP messages is to be neglected.

 

> 2) Reduced Resilience=

> Not only is an aggreg= ate PATH redundant, it actually reduces resilience.

> Because an aggregate = PATH is pinned to interior routers. Therefore, when

> routing changes, it i= s more complex and slower to move to the new route.

> By not pinning to int= erior routers, PCN was designed to 'just work' over

> interior routing chan= ges - with no need for any changes to the RSVP PATHs.

> (But it would still d= etect overload after a re-route and terminate or

> rate-reduce flows if = necessary.)

 

Georgios: I agree with Fra= ncois, when saying that the drawbacks pointed out by Bob are probably not a= s serious as Bob suggested, given that the Aggregated RSVP signaling would be ignored by interior nodes. In particula= r, we don't see why aggregate RSVP signaling would impact rerouting inside = the PCN core since packets from individual sessions would be routed indepen= dently of the reservation.

 

 

> 3) Extra Latency

> A further disadvantag= e is the extra latency required for the first reservation

> that sets up an aggre= gate. This is two ingress-egress round trips minus the

> round trip time from = egress to destination (or one ingress-egress round trip

> if it is greater). Th= is will rarely add to latency on heavily used

> ingress-egress aggreg= ates, but it will occur frequently on all the

> 'long-tail' (lightly = used) ingress-egress aggregates.

 

Georgios: This is only req= uired for the first reservation that sets up an aggregate, which will not o= ccur often. This means that this extra latency is to be neglected.

 

 

> =3D=3DPATH=3D=3D

 

> With RFC 3175 or 4860= aggregate paths, the aggregator forwards the e2e PATH

> messages with IP prot= ocol number RSVP-E2E-IGNORE and the deaggregator changes

> them back to RSVP bef= ore forwarding onward. Also the aggregator sends an

> aggregate PATH messag= e, which is processed by each interior node and by

> the deaggregator.

 

> On a path across a PC= N region, given interior nodes ignore aggregate

> PATH messages as well= , the only PCN nodes that handle aggregate messages

> are the aggregator an= d the deaggregator. The aggregator and deaggregator

> process all the e2e P= ATH messages anyway, so if we require the aggregator

> to add up all the e2e= PATH messages and form them into an aggregate PATH

> message, this is just= extra redundant work for both PCN-edge-nodes.

 

Georgios: But also in the = PCN context it is needed to maintain information about which e2e flows are = associated with a Ingress-Egress-Aggregate, such that when a severe congestion occurs the ingress could release the ac= curate number of the selected e2e flows that are associated with the same I= ngress-Egress-Aggregate.

So an additional protocol = operation has to be specified and implemented in the PCN edge nodes to main= tain this association between e2e flows and the Ingress-Egress-Aggregate states. These additional aggregation based pr= otocol operations are already provided by RFC 4860.  Please see the argumentation= given above of why we should choose RFC 4860 instead of defining a new sol= ution for this purpose.

 

 

 

> =3D=3DRESV=3D=3D

 

> The deaggregator unic= asts e2e RESV messages to the previous RSVP hop,

> which is the aggregat= or. Therefore, if we require the deaggregator

> to add up all the RES= V messages and form them into an aggregate

> RESV message, this is= just redundant work for both PCN-edge-nodes,

> because they both alr= eady process all the e2e RESV messages anyway,

> and no other node use= s the aggregate RESV messages.

 

Georgios: The answer given= above related to the Aggregated PATH message holds also for the Aggregated= RESV message.

 

> =3D=3DPCN object=3D= =3D

 

> This raises the quest= ion of how the PCN-egress communicates the

> various marking rates= (the PCN object) to the PCN-ingress. There

> are two possibilities= :

> i) the PCN-egress inc= ludes a current PCN object in each e2e RESV

> that it returns to th= e PCN-ingress. The PCN-ingress strips the

> PCN object out before= forwarding the RESV back to the previous

> RSVP hop.

 

> ii) the PCN-egress at= taches a PCN object to an aggregate reservation,

> as in pcn-rsvp-03.

 

> Either are possible, = because a PCN object carries information about marking

> probabilities, and PC= N works on the assumption that the marking probability

> of an ingress-egress = aggregate is the same as the marking probability of

> the flows within the = aggregate. A PCN object can be contained either

> in an e2e RESV or an = aggregate RESV as long as the PCN-ingress can

> associate an e2e RESV= with the correct aggregate (which it can, because

> it maintains an inter= nal table of mappings between e2e reservations

> and their aggregates)= .

 

> Which of the two is b= est is a question of message timing...

 

 

> * For e2e admission d= ecisions, the PCN object is only needed at the time

> each e2e RESV is sent= , so option i) makes sense.

 

> * For flow rate reduc= tion or flow termination decisions, the deaggregator

> needs to regularly se= nd PCN objects to the ingress.

 

> The PCN-egress is sen= ding regular e2e RESV refresh messages to the PCN-ingress,

> so a PCN object can b= e included in each of these. To ensure that PCN objects

>  are sent often enough, I suggest the PCN-egress also maintains a tim= er per

> ingress-egress aggreg= ate which it resets every time it sends a PCN object

> for that IEA. If the = timer expires, the PCN-egress sends a PCN object

> to the PCN-egress eve= n thought it was not triggered by an e2e RESV refresh.

> We could require the = SESSION object in this message to refer to either of:

> a) any one of the e2e= SESSIONs in the aggregate,

> b) the aggregate.

 

> In case (a), the mess= age would need to somehow tell the ingress not to forward

> this RESV refresh to = the RSVP previous hop.

 

> In case (b) in the PC= N-ingress table of mappings between e2e SESSIONs and

> aggregate SESSIONs, i= t would include an entry for the aggregate that maps

> to itself. If the res= ult of the look-up is the same as the input, it knows

> not to forward the RE= SV refresh further.

 

> The wire protocol doe= sn't need to identify whether the SESSION is an aggregate

> or not. This is the o= ne case I mentioned at the start {Note 1} where an aggregate

> is referred to on the= wire.

 

Georgios: I do not agree, = using e2e RESV to carry the PCN object has severe drawbacks.<= /p>

In particular, what happen= s in the situation where there is a change of route for a given e2e RSVP re= servation/session (i.e. changing its PCN-ingress-node and/or PCN-egress-node)  rig= ht when the PCN-egress-node decides to use a e2e RSVP signalling message (a= ssociated with this e2e RSVP session) to notify the aggregate PCN informati= on (PCN admission control and/or flow termination information) to the PCN-ingress-node?

In this situation it is po= ssible that the aggregated PCN information (the PCN object) will not be rec= eived by the right PCN-ingress-node, having as implication that the congestion in the PCN domain will not be solved ac= curately and in time!

This problem cannot occur = when an Aggregated RESV message is used to carry the PCN object.

 

 

 

> In summary, PCN alrea= dy reduces reservation state and processing to nothing

> on interior nodes. Ad= ding aggregate reservations to PCN requires more processing

> and state, it unneces= sarily pins routes to interior nodes and adds unnecessary latency.

 

Georgios: As I already men= tioned above, we agree with the proposal of Francois of choosing option (A)=   since the RF= C4860 operations has been thought through and there has been some implement= ation of RSVP Aggregation, so we have some confidence that the solution can deal with the more challenging situa= tions (rerouting in core, failure of an ingress edge, failure of an egress = edge, rerouting towards a different edge,=85).

 

<= span lang=3D"EN-US">Therefore, we have used the argumentat= ion provided by Francois in Section 1.2 of (new draft version) draft-ietf-t= svwg-rsvp-pcn-04 to justify why RFC4860 should be used to accomplish the RSVP over PCN signaling support.

 

Best regards,

Georgios

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE10EXMBX23adutwent_-- From karagian@cs.utwente.nl Sat Mar 9 04:04:56 2013 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D76C21F85E8; Sat, 9 Mar 2013 04:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzs4GYFqx+SB; Sat, 9 Mar 2013 04:04:51 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73E21F85E2; Sat, 9 Mar 2013 04:04:49 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sat, 9 Mar 2013 13:04:50 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.16]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Sat, 9 Mar 2013 13:04:47 +0100 From: To: Thread-Topic: [PCN] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.txt Thread-Index: AQHNw3kdbC91oYHb1EeHisclQ9W2lZid85/pgAACBIM= Date: Sat, 9 Mar 2013 12:04:46 +0000 Message-ID: References: <20121011194603.11308.61516.idtracker@ietfa.amsl.com> , <201211152135.qAFLZ95f010718@bagheera.jungle.bt.co.uk> In-Reply-To: <201211152135.qAFLZ95f010718@bagheera.jungle.bt.co.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE81EXMBX23adutwent_" MIME-Version: 1.0 Cc: pcn@ietf.org, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [PCN] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 12:04:56 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE81EXMBX23adutwent_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bob, Thanks for your comments! Please see in line! > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: donderdag 15 november 2012 22:35 > To: Karagiannis, G. (EWI); Anurag Bhargava (anuragb) > Cc: pcn@ietf.org; tsvwg@ietf.org; rsvp-dir@ietfa.amsl.com > Subject: Re: [PCN] FW: New Version Notification - draft-ietf-tsvwg-rsvp-p= cn- > 03.txt > > Georgios & Anurag, > > Thank you for this draft. Below is my review, as: > - a member of the RSVP directorate > - one of the PCN design team > - a co-author of draft-lefaucheur-rsvp-ecn, on which this draft is based. > > I have already sent my main technical concerns in two separate emails, > summarised below (but I suggest we use the separate threads to discuss): > > 1. It would be easy to allow for an off-path policy-decision point (PDP),= as per > RFC2753 (policy-based admission control (PBAC) framework) Georgios: I replied to your above proposal in a previous email! > > 2. PCN already reduces reservation state and processing to nothing on > interior nodes. Adding aggregate reservations to PCN adds 3 disadvantages > and no advantages: > - it requires more processing and state in interior nodes and boundary- > nodes > - it unnecessarily pins routes to interior nodes and > - it adds unnecessary latency. Georgios: I answered to the thread mentioned above in a previous email sent= today! However, I would like to again emphasize that I strongly agree with= the analysis done by Francois (together with my additional email) in the f= ollowing email on the two options of accomplishing RSVP over PCN signaling = support: http://www.ietf.org/mail-archive/web/tsvwg/current/msg11601.html http://www.ietf.org/mail-archive/web/tsvwg/current/msg11602.html In addition to that, we agree with the proposal of Francois of choosing opt= ion (A) since the RFC4860 operations has been thought through and there ha= s been some implementation of RSVP Aggregation, so we have some confidence = that the solution can deal with the more challenging situations (rerouting = in core, failure of an ingress edge, failure of an egress edge, rerouting t= owards a different edge,=85). Therefore, we have used the argumentation provided by Francois in Section 1= .2 of (new draft version) draft-ietf-tsvwg-rsvp-pcn-04 to justify why RFC48= 60 should be used to accomplish the RSVP over PCN signaling support. > > This email reviews comprehensibility and raises a large number of lesser > technical concerns (26 to be precise), as well as editorial nits (many of= which > may be irrelevant if I'm right about the major technical concerns). > > =3D=3DGeneral style=3D=3D > I didn't find the style useful at all. Sections 1, 2 & 3 defer everything > meaningful into pointers to other RFCs. This makes it incomprehensible, > even if you know all the references intimately. > Lixia's suggestion that you refer to the specific sections of other RFCs = won't > be enough. > > An RFC should be understandable without re-reading its references (reader= s > should have read them, but they shouldn't be expected to remember every > detail). Georgios: We have severely restructured the (new draft) draft-ietf-tsvwg-rs= vp-pcn-04. We believe that the above comment has been worked out! > > I have to say we are moving very slowly, and backwards. When Francois Le > Faucheur first wrote the ancestor to this draft (7 years ago!), I could > understand it immediately, and in half the pages it covered nearly everyt= hing > in this draft and covered the gaps I have listed below. [In the interests= of full > disclosure: I became a co-author of draft-lefaucheur-tsvwg-rsvp-ecn-00, > nonetheless Francois's pre-00 draft was more comprehensible and complete > than this one, even before the co-authors did the first reviews.] Georgios: I do not agree! Note that draft-lefaucheur-tsvwg-rsvp-ecn-00 does= not follow the PCN signaling requirements defined in [RFC6663] and it does= not how it can support the PCN edge behaviors as specified in [RFC6661] an= d [RFC6662]. While draft-ietf-tsvwg-rsvp-pcn-04 certainly does this. > > This draft says very little itself, but ends up much longer. For example = Section > 3 tediously repeats content-free text like: > " > In this document it is considered that for <Title> the same methods can b= e > used as the ones described in <reference>". > > Not only section 3; sections 1 & 2 also rely wholly on references, making > them just as incomprehensible. I also agree with the other reviewers' > suggestions to focus the introduction initially on what this draft adds, = and > move the background material after that. > > In summary: avoid phrases like "the same methods as" or "standard RSVP > aggregation [...] procedures are used". Instead just say directly how it = works. Georgios: We have severely restructured and re-edited the (new draft) draft= -ietf-tsvwg-rsvp-pcn-04. We believe that the above comment has been worked = out! > > > =3D=3DNormative & Technical Points=3D=3D > > =3D=3DGaps=3D=3D > > * How an aggregate reservation is created vs. how one is used if it is al= ready > present Georgios: Done: Added the following text in Section 2.1 to address this iss= ue: =93The procedures for aggregation of E2E reservations over generic aggregat= e RSVP reservations are the same as the procedures specified in Section 4 o= f [RFC4860]. > > * How next hop addresses are discovered (a PCN domain is only one RSVP > hop unlike with RSVP aggregation, so although the process is similar, thi= s > needs to be described explicitly) Georgios: This is explained in the (new draft) draft-ietf-tsvwg-rsvp-pcn-04= . In particular, the PCN-domain is considered as being only one RSVP hop (f= or Generic aggregated RSVP or e2e RSVP). This means that the next RSVP hop = for the Aggregator in the downstream direction is the Deaggregator and the = next RSVP hop for the Deaggregator in the upstream direction is the Aggregator. Furthermore, it is considered that for the determination= of the Deaggregator, the same methods can be used as the ones described in= Section 4 of [RFC4860]. > > * How PCN interior nodes ignore RSVP messages: > - by configuration? > - or by the PCN-ingress switching aggregate PATH messages to IP protocol > number RSVP-E2E-IGNORE (which isn't strictly the right name but would hav= e > the right effect)? > Georgios: We mentioned in the new version of the draft that the PCN interio= r nodes ignore aggregated and e2e RSVP messages by configuration. > * Error conditions, for instance when messages don't contain the expected > objects, e.g. [draft-lefaucheur-tsvwg-rsvp-ecn-01, page 6 bullet 1]. Georgios: Please note that the PCN object is carried using the Aggregated R= ESV message, and not the e2e RESV message, meaning that the above issue is = not relevant. > > * How per-node state is maintained and the interaction with RSVP soft sta= te > refresh messages is not discussed. PCN-related state is unlike other RSVP > state, in that it continually varies (it is controlled by a varying signa= l). > Therefore it needs to be clear that the fields of the PCN object reflect = the > current value when sent, not their original value, which is what an RSVP > implementer would normally expect. Georgios: Please note that the PCN object is carried using the Aggregated R= ESV message, and not the e2e RESV message, meaning that the above issue is = not relevant. > > =3D=3DSpecific sections=3D=3D > > 1. Introduction > > " This document, and according to [RFC4860] MAY also be used end-to-end > directly by end-systems attached to a Diffserv network. > " > No. See RFC5559 for PCN applicability - there is insufficient aggregation= for > PCN to work effectively e2e. The PCN applicability statement in RFC5559 > should be stated here instead: PCN is only applicable to links with > aggregation levels where the bit-rate of the largest flow is tens of time= s > smaller than the smallest available link rate in the PCN region. Georgios: We removed the paragraph pointed out above! > > OLD: > In this document it is considered that the PCN-nodes MUST be able to > support the functionality specified in [RFC5670], [RFC5559], > [RFC6660], [RFC6661], [RFC6662]. > NEW: > To comply with this specification, PCN-nodes MUST be able to > support the functionality specified in [RFC5670], [RFC5559] > [RFC6660], and either [RFC6661] or [RFC6662]. Georgios: Done! > > Section 2.1 first para: > " In addition, in this document it is considered that the PCN-boundary > nodes are able to distinguish and process (1) RSVP SESSIONS for > generic aggregated sessions and their messages according to > [RFC4860], (2) e2e RSVP sessions and messages according to [RFC2205]. > " > Say how (by the addresses that the RSVP messages are addressed to). Georgios: Done! We added text to address this point: =93In addition, to com= ply with this specification it is considered that the PCN-boundary nodes ar= e able to distinguish by using the addresses that the RSVP messages are add= ressed to,=94 > > " Furthermore, it is considered that the PCN-interior-nodes are not > able to distinguish neither RSVP generic aggregated sessions and > their associated messages [RFC4860], nor e2e RSVP sessions and their > associated messages [RFC2205]. > " > Say how (see two possibilities in 'Gaps' above). This is also not > explained in Sections 2.1.7., 3.2 & 3.7, which are all meant to be about = this. Georgios: Done! We added the required information in all the mentioned plac= es. In particular we mentioned that: =93Furthermore, it is considered that by configuration the PCN-interior-nod= es are not able to distinguish neither RSVP generic aggregated sessions and their associated messages [RFC4860], nor e2e RSVP s= essions and their associated messages [RFC2205].=94 > > Section 2.1 bottom of p11: > "The RSVP SESSION object for generic > aggregate reservations is based on the RSVP SESSION object specified > in [RFC4860] augmented with the following information: > > o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be set to the IPv4 > or IPv6 destination addresses, respectively, of the Deaggregator > (PCN-egress-node) > " > Say how - see 'Gaps' above - the whole process of RFC4860 (e2e PATH, > e2e PathErr, aggregate PATH) finds the right address, but this needs > to be described because in PCN the RSVP hop is across multiple IP > nodes (the whole PCN-domain), unlike with RSVP aggregation. Georgios: Done! We have addressed this point, see also gaps above. In the n= ew version of the draft we replaced the above bullet with: o) the IPv4 DestAddress, IPv6 DestAddress MUST be set to the IPv4 or IPv6 destination addresses, respectively, of the Deaggregator (PCN-egress-node), see [RFC4860]. Note that the PCN-domain is considered as being only one RSVP hop (for Generic aggregated RSVP or e2e RSVP). This means that the next RSVP hop for the Aggregator in the downstream direction is the Deaggregator and the next RSVP hop for the Deaggregator in the upstream direction is the Aggregator. Furthermore, it is considered that for the determination of the Deaggregator, the same methods can be used as the ones described in Section 4 of [RFC4860]. > > Section 2.1.2. > " The PCN-traffic (e.g., e2e microflows) belonging to an ingress- > egress-aggregate can be classified only at the PCN-boundary-nodes > using the combination of (1) PCN-BA (i.e., combination of the DSCP > and ECN fields), (2) IP addresses of the specific pair of PCN- > boundary-nodes used by a ingress-egress-aggregate. > [...] > Moreover, the PCN-traffic (e.g., e2e microflows) > belonging to a RSVP generic aggregated reservation can be classified > only at the PCN-boundary-nodes (i.e., Aggregator and Deaggregator) by > using the RSVP SESSION object for RSVP generic aggregated > reservations, see [RFC4860]. > " > Are you assuming a tunnel? You haven't said so? Otherwise the traffic > doesn't contain the PCN-boundary-node addresses. Georgios: Done! We added information saying that it is considered that tunnels need to be used between Aggregators and Deaggregators, using the same procedures as specified in Section 4 of [RFC4860]. > > Section 2.1.8. Inter-domain Routes > > PCN charter scope precludes inter-domain considerations. I personally > would happy to have discussion of inter-domain matters in here, but > it will not be complete, because we would need to discuss security & > integrity of PCN objects, but the PCN charter precluded that. Georgios: Done! We changed this section as below: The PCN-charter scope precludes inter-domain considerations. However, for s= olving inter-domain routes changes associated with the operation of the RSV= P messages, the same methods SHOULD be used as the ones described in [RFC48= 60] and in Section 1.4.7 of [RFC3175]. > > Section 2.1.10. Multi-level Aggregation > " PCN does not consider multi-level aggregations within the PCN domain. > " > You have referenced generic aggregate reservations throughout > [RFC4680], rather than just aggregate reservations [RFC3175]. I > understand the difference is that RFC4860 supports e.g. multiple > levels of precedence. So why say we don't consider multi-level aggregatio= n? Georgios: Done! We replaced the old text with the following one: PCN does not consider multi-level aggregations within the PCN domain. There= fore, the PCN-interior-nodes are not supporting multi-level aggregation pro= cedures. However, the Aggregator and Deaggregator SHOULD support the multi-= level aggregation procedures specified in [RFC4860] and in Section 1.4.9 of= [RFC3175]. > > Section 3.1 > " o) The e2e RSVP reservation session associated with an e2e Path > message that arrives at the external interface of the PCN- > ingress-node is mapped/matched onto an existing RSVP generic > aggregation reservation state. > " > You haven't said how the existing aggregate is created in the first > place (see 'Gaps' above). Georgios: Done! See the gaps description above! > > Section 3.1 (twice) > " A new error code > "PCN-domain rejects e2e reservation" MUST be augmented to the > RSVP error codes to inform the sender that a PCN domains rejects > the e2e reservation request. > " > Disagree. The regular error code "01: Admission Control failure" > should be used, so that end-system implementations understand that > the call has been blocked. > It should also use the regular "Sub-code =3D 2: Requested bandwidth > unavailable". > > If the PCN-ingress uses a different code, it will imply to other RSVP > nodes including end-systems that admission control did not fail. If > it uses the 01 error code but a different sub-code it will imply that > AC failed, but not because of insufficient bandwidth. > > PCN is one (of many) mechanisms to determine whether a reservation > should be blocked. For other nodes, it is not relevant to describe > the mechanism (PCN) that was used to determine that there was > insufficient bandwidth. Georgios: Done! We changed the above mentioned text with: The admission or rejection procedure of a PCN-flow into the PCN-domain is d= efined in detail in: [RFC6661] and [RFC6662]. If the Aggregator is not able to admit the e2e microflow it SHOULD then gen= erate an e2e PathErr message using standard e2e RSVP procedures [RFC4495]. = This e2e PathErr message is sent to the originating sender of the e2e Path = message. The e2e RSVP error code "01: Admission Control failure" and the "S= ub-code =3D 2: Requested bandwidth unavailable " specified in Appendix B of= [RFC2205] SHOULD be used for this purpose. > > Section 3.1 > " o) If for the same ingress-egress-aggregated and the same RSVP > generic aggregated reservation then (1) the PCN-admission- > state and/or (2) the state for the RSVP generic aggregated > reservation are/is "block", the flow SHOULD NOT be > admitted > [...] > The way of how the PCN-admission-state is maintained is specified in > [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated > reservation state is maintained is specified in [RFC4860]. > " > As discussed in my email arguing against aggregate reservations, the > e2e RESV message can carry an up-to-date PCN object for the > PCN-ingress to decide whether to admit the flow signalled by the same > message, given the PCN-ingress already handles e2e RESV messages. > There is no need to rely on admission state determined earlier, given > the PCN-egress already sends an e2e RESV message to the PCN-ingress > at admission time. Georgios: Note that using e2eRESV to carry the PCN object has severe drawba= cks, see above and the previous emails sent by me today. Moreover, the desc= ription that you Bob provide above, on PCN admission control is not in line= with what is defined in the current PCN edge behaviour drafts. > > Section 3.2 and 3.7 (and 2.1.7). > Neither section says how interior nodes are arranged to ignore RSVP > messages (see 'Gaps' earlier which suggests two possible approaches). Georgios: Done, see Gaps description above! > > Section 3.8 (last sentence) > " The address of the PCN-ingress- > node is the one specified in the same ingress-egress-aggregate." > I cannot work out how Georgios: Done! We have added the following text: It is considered that the ingress-egress-aggregate state stores both IP add= resses of the PCN-ingress-node, i.e., Aggregator, and of the IP-egress-node= , i.e., Deaggregator. > > Section 3.11 > Separation of the policy enforcement role of the PCN-ingress from a > policy decision role (that may be off-path) will need to be added to > the first bullet of this section (see other email). Georgios: We disagree with this comment! We think that the description of s= uch a policy-based admission control (PBAC) architecture is not in the scop= e of this draft. See also my previous email sent today! We however, tried to work out this comment by including the following text: =93o) If the Decision Point is not collocated with the PCN-ingress- node, then other procedures need to be specified of handling the Aggregated Resv Message by the Aggregating router, i.e., PCN- ingress-node. These procedures are out of the scope of this document. o) If the Decision point is collocated with the PCN-ingress-node, then the PCN-ingress-node (i.e. Aggregator) ..=94 > > Section 3.11 > " However, based on a local policy, the Aggregator could use > other procedures of terminating microflows. > " > Please delete. Policy determines /which/ flows are terminated, not > /how/ the termination procedure works. Georgios: Done! We tried to work out this comment by modifying the text as = follows: =93However, based on a local policy, the Aggregator could use other ways of= selecting which microflows should be terminated.=94 > > Section 3.12 > I don't understand the purpose of this section - section 3.11 seems > to have already said everything that section 3.12 says. Georgios: We re-edit the section to satisfy the above comment! > > Section 3.13 > Say why an aggregate reservation would need to be removed: > - no e2e reservations left in the aggregate? > - such severe pre-congestion that every flow in the aggregated has to > be terminated (!!!???) > Georgios: Done! We reedited the section to comply with this comment! > Section 4. Protocol Elements > " The protocol elements in this document are using the protocol > Elements defined in [RFC4860], augmented with the following rules: > " > This doc uses a number of protocol elements from the base RSVP spec, > not just the extras defined in RFC4860. > > BTW, protocol elements are generally called classes in RSVP documents > (and instances of them are called objects). Also the grammar and > capitalisation in this sentence is pretty poor. Georgios: Please note that we used the same terms (related to protocol elem= ents) as the ones used in RFC4860 and RFC3175. > > Section 4. Protocol Elements > The first two bullets are inappropriate here and more appropriate to sect= ion > 3. Georgios: These two bullets are used i this section to increase the clarity= of the specification! > > Section 4.1 PCN Object > > I don't see why the PCN object needs to contain the IP addresses of > the PCN-ingress and PCN-egress. These will be in the SESSION object > earlier in the list of RSVP objects, and RFC2205 says that the > SESSION object defines the session for the other objects that follow. > This also means we don't need different PCN objects for IPv4 & IPv6. Georgios: We provided text in the new draft draft-ietf-tsvwg-rsvp-pcn-04, t= hat emphasizes that according to [RFC6663] the report should carry the iden= tifier of the PCN-ingress-node and the identifier of the PCN-egress-node (t= ypically their IP addresses). This means that the different types for PCN objects for IPv4 & IPv6 are nee= ded. > > Section 4.1 PCN Object > > s/rate/fraction/ > I don't think you mean rate, which implies with respect to time. I > think you mean the fraction of bytes in packets with each marking > relative to the total bytes in PCN marked packets. Georgios: It is rate (respect to time), please see [RFC6663] and [RFC6661] = and [RFC6662]. > > Section 4.1 PCN Object > > I suggest that the PCN object always reports the fractions of all > three non-zero values of the PCN (aka ECN) field, even for single > marking (SM) mode that doesn't use one of the codepoints. Then > PCN-egress implementations and the PCN object on the wire can be the > same for both SM & CL modes (I think), and only the ingress has to be > different. Georgios: Sorry, but the above description is not in line with RFC6663] and= [RFC6661] and [RFC6662]. > > Section 4.1 PCN Object (and IANA Considerations) > > IANA need to be told the high order 2 bits of the Class-Num, to > exploit the Unknown Class rules of [RFC2205, section 3.10]. I suggest > the Class-Num is 10bbbbbb, so that any node outside a PCN domain that > receives a PCN object and doesn't understand it will strip it off and > forward the remainder of the RSVP message. Ideally we would want the > RSVP message (with or without the PCN object) to be forwarded and an > error message raised, but that option is not available; RSVP only > allows an error message to be raised when it discards a whole message. Georgios: Please note that the PCN object is carried by the Aggregated RESV= message. This message does not go out the PCN domain. Thus the above descr= ibed issue is not relevant for this draft. > > Section 4.1 PCN Object > > The section defines a PCN CL Flow IDs object. It's not clear whether > it is meant to be a different object from the PCN object, or an > extension to it. I think it would be clearer to make it a separate > RSVP object, although in theory a PCN-ingress could work out that a > PCN CL Flow IDs object is included, by a calculation from the object > length (because the base PCN object is always a fixed length). > > I don't see the point of the LENGTH field (for the number of flow ID > objects), given RSVP gives the length of an object in octets, from > which the number of flow ID objects can be derived (divide by 16 for > IPv4 or divide by 40 for IPv6). Also RSVP objects have to align on 4 > octet boundaries. Georgios: Please note that the PCN CL Flow IDs object is considered to be a= different PCN object, since its frequency and functionality is very much d= ifferent than the frequency and functionality of the other PCN objects. Regarding the length, I do not understand the comment, since such length fi= eld is necessary, due to e.g., variable length of the object. > > > > =3D=3DEditorial Nits=3D=3D > > Globally: > s/In this document it is considered that.../ > /To comply with this specification.../ Georgios: Done! > > Abstract: > s/specifies the extensions to/ > /specifies extensions to/ Georgios: Done! > > 1. Intro > s/collocated/ > /colocated/ > s/extensions to the Generic Aggregated RSVP [RFC4860] for the support of/ > /extensions to Generic Aggregated RSVP [RFC4860] for support of/ Georgios: Done! > > OLD > Furthermore, this document and according to [RFC4860], in absence of > e2e RSVP flows, a variety of policies (not defined in this document) > can be used at the Aggregator to set the DSCP of packets passing into > the aggregation region and how they are mapped onto generic aggregate > reservations. These policies are not described in this document but > are a matter of local configuration. > NEW > In a similar way to [RFC4860], the Aggregator can detect flows > based on policy > (not defined in this document) rather than using e2e RSVP flow > signalling. Then > it can map them onto aggregate reservations and set the DSCP of > the packets of > these flows as they pass into the aggregation region. Georgios: The above mentioned paragraph is deleted completely from the draf= t! > > Section 1.1. Terminology > > " Ingress-egress-aggregate (IEA): > [...] > combination of (1) fields), (2) IP addresses of the > " > Some text appears to be missing here. > > Section 1.1. Terminology > OLD: > t-recvFail > An ingress-egress-aggregate timer that is used at > The Decision point (in this document at the PCN- > ingress-node) which when expires raises an alarm to > management, and activates the PCN-ingress-node to > block the admission of new PCN-flows. This timer > expires when it value is equal to T-fail and is > reset when a report, i.e., RSVP aggregated RESV > message, is received for a RSVP generic aggregated > reservation (which is matched to one > ingress-egress-aggregate). > NEW: > t-recvFail > A timer per ingress-egress-aggregate that the > PCN-ingress-node > sets every time it receives an RSVP RESV message for that > ingress-egress-aggregate. When its value reaches T-fail > it is assumed that the PCN-ingress has lost > contact with the > PCN-egress. Therefore the PCN-ingress blocks > admission of new > PCN-flows into that aggregate and raises a > management alarm. > REASONING: > The order in which the clauses were written made it hard to > understand, there was nothing to say what it measured, and it wasn't > clear what scope was implied by "it blocks PCN-flows". Georgios: Done! Please note that we also replaced =93RSVP RESV=94 with =93R= SVP Aggregated RESV=94. > > Section 1.1 Terminology > > Underscores (e.g t_meas) are often used in the terminology section, > whereas hyphens (e.g. t-meas) are used in the body text. Georgios: Done! > > Section 2.1 Overview > > There is no Section 2.2, so all the sub-sections of 2.1.X could be promot= ed. Georgios: Done! > > Section 2.1.1 > s/used, SHOULD/used SHOULD/ Georgios: Done! > > Section 2.1.2. > OLD: > The PCN-traffic is marked using PCN-marking and is classified using > The PCN-BA (i.e., combination of the DSCP and ECN fields). > NEW: > The PCN-ingress marks a PCN-BA useing PCN-marking (i.e., > combination of the DSCP and ECN fields), which interior nodes use to > classify PCN-traffic. > REASONING: > Avoid passive verbs - ambiguous. Georgios: Done! > > Section 2.1.3 > s/for the determination of/to determine the address of/ Georgios: Done! > > Section 2.1.4 > " o) PCN-ingress-node MUST use one or more policies to estimate whether > an e2e RSVP reservation session associated with an e2e Path > message that arrives at the external interface of the PCN-ingress- > node can be mapped onto an existing RSVP generic aggregation > reservation state. > " > This is a straightforward mapping function, it shouldn't involve policy. > Also mappings are deterministic - the word estimate is wrong. Georgios: We replaced the words =93to estimate=94 with =93to determine=94 > > Section 3.1 > " o) If the timer t-recvFail expires [...] > o) If the timer t-recvFail does NOT expire [...] > " > Switch the order of these two bullets, to describe the normal > (successful) behaviour first. Georgios: Done! > > Section 3.1 > > s/ingress-egress-aggregated/ > /ingress-egress-aggregate/ > s/then (1)/ > /(1) Georgios: Done! > [However, I suggest earlier that the technical sense should be > substantially changed, possibly making these editorial changes irrelevant= .] > > Section 3.8. > OLD: > The PCN object is specified in > this document and is used for the report of the data measured by > the PCN-egress-node, for a particular ingress-egress-aggregate, > see [RFC6661], and [RFC6662]. > NEW: > The PCN-egress-node reports the marking probabilities it measures for > a particular ingress-egress-aggregate in a PCN object, as specified in > Section 4 (see also [RFC6661], and [RFC6662]). > REASONING: > Poor sentence order. Georgios: Done! Re-edited! > > Section 3.11. > s/associated to one ingress-egress-aggregate/ > /associated with one ingress-egress-aggregate/ Georgios: Done! > > Section 3.15 > Repeats Section 2.1.9. Unnecessary. Georgios: The context of the two sections is slightly different! Therefore,= I would like to leave them! > > Section 4. > s/by an PCN-egress node/ > /by a PCN-egress node/ Georgios: Done! Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE81EXMBX23adutwent_ Content-Type: text/html; charset="Windows-1252" Content-ID: <167779B49D20F24484B717785C3F3FE9@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style>.EmailQuote { BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt } </style><style id=3D"owaParaStyle">P { MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px } </style> </head> <body ocsi=3D"0" fPStyle=3D"1"> <font size=3D"2"><span style=3D"FONT-SIZE: 10pt"></span></font> <div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ= E: 10pt"> <p>Hi Bob,</p> <p> </p> <p>Thanks for your comments!<br> Please see in line!</p> <p> </p> <p>> -----Original Message-----<br> > From: Bob Briscoe [mailto:bob.briscoe@bt.com]<br> > Sent: donderdag 15 november 2012 22:35<br> > To: Karagiannis, G. (EWI); Anurag Bhargava (anuragb)<br> > Cc: <a href=3D"mailto:pcn@ietf.org" target=3D"_blank">pcn@ietf.org</a>= ; <a href=3D"mailto:tsvwg@ietf.org" target=3D"_blank"> tsvwg@ietf.org</a>; <a href=3D"mailto:rsvp-dir@ietfa.amsl.com" target=3D"_b= lank">rsvp-dir@ietfa.amsl.com</a><br> > Subject: Re: [PCN] FW: New Version Notification - draft-ietf-tsvwg-rsv= p-pcn-<br> > 03.txt<br> > <br> > Georgios & Anurag,<br> > <br> > Thank you for this draft. Below is my review, as:<br> > - a member of the RSVP directorate<br> > - one of the PCN design team<br> > - a co-author of draft-lefaucheur-rsvp-ecn, on which this draft is bas= ed.<br> > <br> > I have already sent my main technical concerns in two separate emails,= <br> > summarised below (but I suggest we use the separate threads to discuss= ):<br> > <br> > 1. It would be easy to allow for an off-path policy-decision point (PD= P), as per<br> > RFC2753 (policy-based admission control (PBAC) framework)</p> <p>Georgios: I replied to your above proposal in a previous email!<br> > <br> > 2. PCN already reduces reservation state and processing to nothing on<= br> > interior nodes. Adding aggregate reservations to PCN adds 3 disadvanta= ges<br> > and no advantages:<br> > - it requires more processing and state in interior nodes and boundary= -<br> > nodes<br> > - it unnecessarily pins routes to interior nodes and<br> > - it adds unnecessary latency.</p> <p> </p> <p>Georgios: I answered to the thread mentioned above in a previous email s= ent today! However, I would like to again emphasize that I strongly agree w= ith the analysis done by Francois (together with my additional email) in th= e following email on the two options of accomplishing RSVP over PCN signaling support:<br> <a href=3D"http://www.ietf.org/mail-archive/web/tsvwg/current/msg11601.html= " target=3D"_blank">http://www.ietf.org/mail-archive/web/tsvwg/current/msg1= 1601.html</a><br> <a href=3D"http://www.ietf.org/mail-archive/web/tsvwg/current/msg11602.html= " target=3D"_blank">http://www.ietf.org/mail-archive/web/tsvwg/current/msg1= 1602.html</a></p> <p>In addition to that, we agree with the proposal of Francois of choosing = option (A)  since the RFC4860 operations has been thought through and = there has been some implementation of RSVP Aggregation, so we have some con= fidence that the solution can deal with the more challenging situations (rerouting in core, failure of an ingress = edge, failure of an egress edge, rerouting towards a different edge,=85).</= p> <p>Therefore, we have used the argumentation provided by Francois in Sectio= n 1.2 of (new draft version) draft-ietf-tsvwg-rsvp-pcn-04 to justify why RF= C4860 should be used to accomplish the RSVP over PCN signaling support.</p> <p><br> > <br> > This email reviews comprehensibility and raises a large number of less= er<br> > technical concerns (26 to be precise), as well as editorial nits (many= of which<br> > may be irrelevant if I'm right about the major technical concerns).<br= > > <br> > =3D=3DGeneral style=3D=3D<br> > I didn't find the style useful at all. Sections 1, 2 & 3 defer eve= rything<br> > meaningful into pointers to other RFCs. This makes it incomprehensible= ,<br> > even if you know all the references intimately.<br> > Lixia's suggestion that you refer to the specific sections of other RF= Cs won't<br> > be enough.<br> > <br> > An RFC should be understandable without re-reading its references (rea= ders<br> > should have read them, but they shouldn't be expected to remember ever= y<br> > detail).</p> <p> </p> <p>Georgios: We have severely restructured the (new draft) draft-ietf-tsvwg= -rsvp-pcn-04. We believe that the above comment has been worked out!</p> <p> </p> <p>> <br> > I have to say we are moving very slowly, and backwards. When Francois = Le<br> > Faucheur first wrote the ancestor to this draft (7 years ago!), I coul= d<br> > understand it immediately, and in half the pages it covered nearly eve= rything<br> > in this draft and covered the gaps I have listed below. [In the intere= sts of full<br> > disclosure: I became a co-author of draft-lefaucheur-tsvwg-rsvp-ecn-00= ,<br> > nonetheless Francois's pre-00 draft was more comprehensible and comple= te<br> > than this one, even before the co-authors did the first reviews.]</p> <p>Georgios: I do not agree! Note that draft-lefaucheur-tsvwg-rsvp-ecn-00 d= oes not follow the PCN signaling requirements defined in [RFC6663] and it d= oes not how it can support the PCN edge behaviors as specified in [RFC6661]= and [RFC6662]. While draft-ietf-tsvwg-rsvp-pcn-04 certainly does this.</p> <p> </p> <p>> <br> > This draft says very little itself, but ends up much longer. For examp= le Section<br> > 3 tediously repeats content-free text like:<br> > "<Title><br> > In this document it is considered that for <Title> the same meth= ods can be<br> > used as the ones described in <reference>".<br> > <br> > Not only section 3; sections 1 & 2 also rely wholly on references,= making<br> > them just as incomprehensible. I also agree with the other reviewers'<= br> > suggestions to focus the introduction initially on what this draft add= s, and<br> > move the background material after that.<br> > <br> > In summary: avoid phrases like "the same methods as" or &quo= t;standard RSVP<br> > aggregation [...] procedures are used". Instead just say directly= how it works.</p> <p> </p> <p>Georgios: We have severely restructured and re-edited the (new draft) dr= aft-ietf-tsvwg-rsvp-pcn-04. We believe that the above comment has been work= ed out!</p> <p> </p> <p>> <br> > <br> > =3D=3DNormative & Technical Points=3D=3D<br> > <br> > =3D=3DGaps=3D=3D<br> > <br> > * How an aggregate reservation is created vs. how one is used if it is= already<br> > present</p> <p> </p> <p>Georgios: Done: Added the following text in Section 2.1 to address this = issue:<br> =93The procedures for aggregation of E2E reservations over generic aggregat= e RSVP reservations are the same as the procedures specified in Section 4 o= f [RFC4860]. </p> <p> </p> <p>> <br> > * How next hop addresses are discovered (a PCN domain is only one RSVP= <br> > hop unlike with RSVP aggregation, so although the process is similar, = this<br> > needs to be described explicitly)</p> <p> </p> <p>Georgios: This is explained in the (new draft) draft-ietf-tsvwg-rsvp-pcn= -04. In particular, the PCN-domain is considered as being only one RSVP hop= (for Generic aggregated RSVP or e2e RSVP). This means that the next RSVP h= op for the Aggregator in the downstream direction is the Deaggregator and the  next RSVP hop for the Deaggreg= ator in the upstream direction <br> is the Aggregator. Furthermore, it is considered that for the determination= of the Deaggregator, the same methods can be used as the ones described in= Section 4 of [RFC4860].  </p> <p><br> > <br> > * How PCN interior nodes ignore RSVP messages:<br> > - by configuration?<br> > - or by the PCN-ingress switching aggregate PATH messages to IP protoc= ol<br> > number RSVP-E2E-IGNORE (which isn't strictly the right name but would = have<br> > the right effect)?<br> > </p> <p> </p> <p>Georgios: We mentioned in the new version of the draft that the PCN inte= rior nodes ignore aggregated and e2e RSVP messages by configuration. </p> <p> </p> <p>> * Error conditions, for instance when messages don't contain the ex= pected<br> > objects, e.g. [draft-lefaucheur-tsvwg-rsvp-ecn-01, page 6 bullet 1].</= p> <p> </p> <p>Georgios: Please note that the PCN object is carried using the Aggregate= d RESV message, and not the e2e RESV message, meaning that the above issue = is not relevant. </p> <p><br> > <br> > * How per-node state is maintained and the interaction with RSVP soft = state<br> > refresh messages is not discussed. PCN-related state is unlike other R= SVP<br> > state, in that it continually varies (it is controlled by a varying si= gnal).<br> > Therefore it needs to be clear that the fields of the PCN object refle= ct the<br> > current value when sent, not their original value, which is what an RS= VP<br> > implementer would normally expect.</p> <p> </p> <p>Georgios: Please note that the PCN object is carried using the Aggregate= d RESV message, and not the e2e RESV message, meaning that the above issue = is not relevant.</p> <p><br> > <br> > =3D=3DSpecific sections=3D=3D<br> > <br> > 1. Introduction<br> > <br> > " This document, and according to [RFC4860] MAY also be used end-= to-end<br> > directly by end-systems attached to a Diffserv network.<br> > "<br> > No. See RFC5559 for PCN applicability - there is insufficient aggregat= ion for<br> > PCN to work effectively e2e. The PCN applicability statement in RFC555= 9<br> > should be stated here instead: PCN is only applicable to links with<br= > > aggregation levels where the bit-rate of the largest flow is tens of t= imes<br> > smaller than the smallest available link rate in the PCN region.</p> <p> </p> <p>Georgios: We removed the paragraph pointed out above!</p> <p> </p> <p>> <br> > OLD:<br> > In this document it is considered that the PCN-nodes MUST be able to<b= r> > support the functionality specified in [RFC5670], [RFC5559],<br> > [RFC6660], [RFC6661], [RFC6662].<br> > NEW:<br> > To comply with this specification, PCN-nodes MUST be able to<br> > support the functionality specified in [RFC5670], [RFC5559]<br> > [RFC6660], and either [RFC6661] or [RFC6662].</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 2.1 first para:<br> > " In addition, in this document it is considered that the PCN-bou= ndary<br> > nodes are able to distinguish and process (1) RSVP SESSIONS for<br> > generic aggregated sessions and their messages according to<br> > [RFC4860], (2) e2e RSVP sessions and messages according to [RFC2205].<= br> > "<br> > Say how (by the addresses that the RSVP messages are addressed to).</p= > <p> </p> <p>Georgios: Done! We added text to address this point: =93In addition, to = comply with this specification it is considered that the PCN-boundary nodes= are able to distinguish by using the addresses that the RSVP messages are = addressed to,=94</p> <p><br> > <br> > " Furthermore, it is considered that the PCN-interior-nodes are n= ot<br> > able to distinguish neither RSVP generic aggregated sessions and<br> > their associated messages [RFC4860], nor e2e RSVP sessions and their<b= r> > associated messages [RFC2205].<br> > "<br> > Say how (see two possibilities in 'Gaps' above). This is also not<br> > explained in Sections 2.1.7., 3.2 & 3.7, which are all meant to be= about this.</p> <p><br> Georgios: Done! We added the required information in all the mentioned plac= es. In particular we mentioned that:</p> <p>=93Furthermore, it is considered that by configuration the PCN-interior-= nodes are not able to distinguish neither RSVP generic <br> aggregated sessions and their associated messages [RFC4860], nor e2e RSVP s= essions and their associated messages [RFC2205].=94</p> <p><br> > <br> > Section 2.1 bottom of p11:<br> > "The RSVP SESSION object for generic<br> > aggregate reservations is based on the RSVP SESSION object specified<b= r> > in [RFC4860] augmented with the following information:<br> > <br> > o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be set to the IPv4<br= > > or IPv6 destination addresses, respectively, of the Deaggregator<br> > (PCN-egress-node)<br> > "<br> > Say how - see 'Gaps' above - the whole process of RFC4860 (e2e PATH,<b= r> > e2e PathErr, aggregate PATH) finds the right address, but this needs<b= r> > to be described because in PCN the RSVP hop is across multiple IP<br> > nodes (the whole PCN-domain), unlike with RSVP aggregation.</p> <p> </p> <p>Georgios: Done! We have addressed this point, see also gaps above. In th= e new version of the draft we replaced the above bullet with:</p> <p>    o) the IPv4 DestAddress, IPv6 DestAddress MUST be set= to the IPv4 <br>        or IPv6 destination addresses, respect= ively, of the Deaggregator <br>       (PCN-egress-node), see [RFC4860]. Note that = the PCN-domain is <br>        considered as being only one RSVP hop = (for Generic aggregated <br>        RSVP or e2e RSVP). This means that the= next RSVP hop for the <br>        Aggregator in the downstream direction= is the Deaggregator and <br>        the  next RSVP hop for the Deaggr= egator in the upstream direction <br>        is the Aggregator. Furthermore, it is = considered that for the <br>        determination of the Deaggregator, the= same methods can be used <br>        as the ones described in Section 4 of = [RFC4860].  </p> <p><br> > <br> > Section 2.1.2.<br> > " The PCN-traffic (e.g., e2e microflows) belonging to an ingress-= <br> > egress-aggregate can be classified only at the PCN-boundary-nodes<br> > using the combination of (1) PCN-BA (i.e., combination of the DSCP<br> > and ECN fields), (2) IP addresses of the specific pair of PCN-<br> > boundary-nodes used by a ingress-egress-aggregate.<br> > [...]<br> > Moreover, the PCN-traffic (e.g., e2e microflows)<br> > belonging to a RSVP generic aggregated reservation can be classified<b= r> > only at the PCN-boundary-nodes (i.e., Aggregator and Deaggregator) by<= br> > using the RSVP SESSION object for RSVP generic aggregated<br> > reservations, see [RFC4860].<br> > "<br> > Are you assuming a tunnel? You haven't said so? Otherwise the traffic<= br> > doesn't contain the PCN-boundary-node addresses.</p> <p> </p> <p>Georgios: Done! We added information saying that it is <br>    considered that tunnels need to be used between Aggregators an= d  <br>    Deaggregators, using the same procedures as specified in Secti= on 4 of <br>    [RFC4860].</p> <p> </p> <p>> <br> > Section 2.1.8. Inter-domain Routes<br> > <br> > PCN charter scope precludes inter-domain considerations. I personally<= br> > would happy to have discussion of inter-domain matters in here, but<br= > > it will not be complete, because we would need to discuss security &am= p;<br> > integrity of PCN objects, but the PCN charter precluded that.</p> <p> </p> <p>Georgios: Done! We changed this section as below:</p> <p>The PCN-charter scope precludes inter-domain considerations. However, fo= r solving inter-domain routes changes associated with the operation of the = RSVP messages, the same methods SHOULD be used as the ones described in [RF= C4860] and in Section 1.4.7 of [RFC3175]. </p> <p> </p> <p>> <br> > Section 2.1.10. Multi-level Aggregation<br> > " PCN does not consider multi-level aggregations within the PCN d= omain.<br> > "<br> > You have referenced generic aggregate reservations throughout<br> > [RFC4680], rather than just aggregate reservations [RFC3175]. I<br> > understand the difference is that RFC4860 supports e.g. multiple<br> > levels of precedence. So why say we don't consider multi-level aggrega= tion?</p> <p> </p> <p>Georgios: Done! We replaced the old text with the following one:<br> PCN does not consider multi-level aggregations within the PCN domain. There= fore, the PCN-interior-nodes are not supporting multi-level aggregation pro= cedures. However, the Aggregator and Deaggregator SHOULD support the multi-= level aggregation procedures specified in [RFC4860] and in Section 1.4.9 of [RFC3175]. </p> <p> </p> <p>> <br> > Section 3.1<br> > " o) The e2e RSVP reservation session associated with an e2e Path= <br> > message that arrives at the external interface of the PCN-<br> > ingress-node is mapped/matched onto an existing RSVP generic<br> > aggregation reservation state.<br> > "<br> > You haven't said how the existing aggregate is created in the first<br= > > place (see 'Gaps' above).</p> <p> </p> <p>Georgios: Done! See the gaps description above!</p> <p> </p> <p>> <br> > Section 3.1 (twice)<br> > " A new error code<br> > "PCN-domain rejects e2e reservation" MUST be augmented to th= e<br> > RSVP error codes to inform the sender that a PCN domains rejects<br> > the e2e reservation request.<br> > "<br> > Disagree. The regular error code "01: Admission Control failure&q= uot;<br> > should be used, so that end-system implementations understand that<br> > the call has been blocked.<br> > It should also use the regular "Sub-code =3D 2: Requested bandwid= th<br> > unavailable".<br> > <br> > If the PCN-ingress uses a different code, it will imply to other RSVP<= br> > nodes including end-systems that admission control did not fail. If<br= > > it uses the 01 error code but a different sub-code it will imply that<= br> > AC failed, but not because of insufficient bandwidth.<br> > <br> > PCN is one (of many) mechanisms to determine whether a reservation<br> > should be blocked. For other nodes, it is not relevant to describe<br> > the mechanism (PCN) that was used to determine that there was<br> > insufficient bandwidth.</p> <p> </p> <p>Georgios: Done! We changed the above mentioned text with:<br> The admission or rejection procedure of a PCN-flow into the PCN-domain is d= efined in detail in: [RFC6661] and [RFC6662]. <br> If the Aggregator is not able to admit the e2e microflow it SHOULD then gen= erate an e2e PathErr message using standard e2e RSVP procedures [RFC4495]. = This e2e PathErr message is sent to the originating sender of the e2e Path = message. The e2e RSVP error code "01: Admission Control failure" and the "Sub-code =3D 2: Re= quested bandwidth unavailable " specified in Appendix B of [RFC2205] S= HOULD be used for this purpose. </p> <p><br> > <br> > Section 3.1<br> > " o) If for the same ingress-egress-aggregated and the same RSVP<= br> > generic aggregated reservation then (1) the PCN-admission-<br> > state and/or (2) the state for the RSVP generic aggregated<br> > reservation are/is "block", the flow SHOULD NOT be<br> > admitted<br> > [...]<br> > The way of how the PCN-admission-state is maintained is specified in<b= r> > [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated<br= > > reservation state is maintained is specified in [RFC4860].<br> > "<br> > As discussed in my email arguing against aggregate reservations, the<b= r> > e2e RESV message can carry an up-to-date PCN object for the<br> > PCN-ingress to decide whether to admit the flow signalled by the same<= br> > message, given the PCN-ingress already handles e2e RESV messages.<br> > There is no need to rely on admission state determined earlier, given<= br> > the PCN-egress already sends an e2e RESV message to the PCN-ingress<br= > > at admission time.</p> <p> </p> <p>Georgios: Note that using e2eRESV to carry the PCN object has severe dra= wbacks, see above and the previous emails sent by me today. Moreover, the d= escription that you Bob provide above, on PCN admission control is not in l= ine with what is defined in the current PCN edge behaviour drafts.</p> <p> </p> <p><br> > <br> > Section 3.2 and 3.7 (and 2.1.7).<br> > Neither section says how interior nodes are arranged to ignore RSVP<br= > > messages (see 'Gaps' earlier which suggests two possible approaches).<= /p> <p> </p> <p>Georgios: Done, see Gaps description above!</p> <p> </p> <p>> <br> > Section 3.8 (last sentence)<br> > " The address of the PCN-ingress-<br> > node is the one specified in the same ingress-egress-aggregate."<= br> > I cannot work out how</p> <p> </p> <p>Georgios: Done! We have added the following text:</p> <p>It is considered that the ingress-egress-aggregate state stores both IP = addresses of the PCN-ingress-node, i.e., Aggregator, and of the IP-egress-n= ode, i.e., Deaggregator.</p> <p> </p> <p>> <br> > Section 3.11<br> > Separation of the policy enforcement role of the PCN-ingress from a<br= > > policy decision role (that may be off-path) will need to be added to<b= r> > the first bullet of this section (see other email).</p> <p> </p> <p>Georgios: We disagree with this comment! We think that the description o= f such a policy-based admission control (PBAC) architecture is not in the s= cope of this draft. See also my previous email sent today!<br> We however, tried to work out this comment by including the following text:= </p> <p>    =93o)  If the Decision Point is not collocated w= ith the PCN-ingress-<br>         node, then other procedures need= to be specified of handling the <br>         Aggregated Resv Message by the A= ggregating router, i.e., PCN-<br>         ingress-node. These procedures a= re out of the scope of this <br>         document.</p> <p>    o)  If the Decision point is collocated with the= PCN-ingress-node, <br>         then the PCN-ingress-node (i.e. = Aggregator) ..=94  </p> <p> </p> <p>> <br> > Section 3.11<br> > " However, based on a local policy, the Aggregator could use<br> > other procedures of terminating microflows.<br> > "<br> > Please delete. Policy determines /which/ flows are terminated, not<br> > /how/ the termination procedure works.</p> <p> </p> <p>Georgios: Done! We tried to work out this comment by modifying the text = as follows:<br> =93However, based on a local policy, the Aggregator could use other ways of= selecting which microflows should be terminated.=94</p> <p> </p> <p>> <br> > Section 3.12<br> > I don't understand the purpose of this section - section 3.11 seems<br= > > to have already said everything that section 3.12 says.</p> <p> </p> <p>Georgios: We re-edit the section to satisfy the above comment!</p> <p> </p> <p>> <br> > Section 3.13<br> > Say why an aggregate reservation would need to be removed:<br> > - no e2e reservations left in the aggregate?<br> > - such severe pre-congestion that every flow in the aggregated has to<= br> > be terminated (!!!???)<br> > </p> <p> </p> <p>Georgios: Done! We reedited the section to comply with this comment!</p> <p><br> > Section 4. Protocol Elements<br> > " The protocol elements in this document are using the protocol<b= r> > Elements defined in [RFC4860], augmented with the following rules:<br> > "<br> > This doc uses a number of protocol elements from the base RSVP spec,<b= r> > not just the extras defined in RFC4860.<br> > <br> > BTW, protocol elements are generally called classes in RSVP documents<= br> > (and instances of them are called objects). Also the grammar and<br> > capitalisation in this sentence is pretty poor.</p> <p> </p> <p>Georgios: Please note that we used the same terms (related to protocol e= lements) as the ones used in RFC4860 and RFC3175.</p> <p><br> > <br> > Section 4. Protocol Elements<br> > The first two bullets are inappropriate here and more appropriate to s= ection<br> > 3.</p> <p> </p> <p>Georgios: These two bullets are used i this section to increase the clar= ity of the specification!</p> <p> </p> <p>> <br> > Section 4.1 PCN Object<br> > <br> > I don't see why the PCN object needs to contain the IP addresses of<br= > > the PCN-ingress and PCN-egress. These will be in the SESSION object<br= > > earlier in the list of RSVP objects, and RFC2205 says that the<br> > SESSION object defines the session for the other objects that follow.<= br> > This also means we don't need different PCN objects for IPv4 & IPv= 6.</p> <p> </p> <p>Georgios: We provided text in the new draft draft-ietf-tsvwg-rsvp-pcn-04= , that emphasizes that according to [RFC6663] the report should carry the i= dentifier of the PCN-ingress-node and the identifier of the PCN-egress-node= (typically their IP addresses).<br> This means that the different types for PCN objects for IPv4 & IPv6 are= needed.</p> <p> </p> <p>> <br> > Section 4.1 PCN Object<br> > <br> > s/rate/fraction/<br> > I don't think you mean rate, which implies with respect to time. I<br> > think you mean the fraction of bytes in packets with each marking<br> > relative to the total bytes in PCN marked packets.</p> <p> </p> <p>Georgios: It is rate (respect to time), please see [RFC6663] and [RFC666= 1] and [RFC6662].</p> <p> </p> <p>> <br> > Section 4.1 PCN Object<br> > <br> > I suggest that the PCN object always reports the fractions of all<br> > three non-zero values of the PCN (aka ECN) field, even for single<br> > marking (SM) mode that doesn't use one of the codepoints. Then<br> > PCN-egress implementations and the PCN object on the wire can be the<b= r> > same for both SM & CL modes (I think), and only the ingress has to= be</p> <p>> different.</p> <p> </p> <p>Georgios: Sorry, but the above description is not in line with RFC6663] = and [RFC6661] and [RFC6662].</p> <p><br> > <br> > Section 4.1 PCN Object (and IANA Considerations)<br> > <br> > IANA need to be told the high order 2 bits of the Class-Num, to<br> > exploit the Unknown Class rules of [RFC2205, section 3.10]. I suggest<= br> > the Class-Num is 10bbbbbb, so that any node outside a PCN domain that<= br> > receives a PCN object and doesn't understand it will strip it off and<= br> > forward the remainder of the RSVP message. Ideally we would want the<b= r> > RSVP message (with or without the PCN object) to be forwarded and an<b= r> > error message raised, but that option is not available; RSVP only<br> > allows an error message to be raised when it discards a whole message.= </p> <p> </p> <p>Georgios: Please note that the PCN object is carried by the Aggregated R= ESV message. This message does not go out the PCN domain. Thus the above de= scribed issue is not relevant for this draft.</p> <p> </p> <p>> <br> > Section 4.1 PCN Object<br> > <br> > The section defines a PCN CL Flow IDs object. It's not clear whether<b= r> > it is meant to be a different object from the PCN object, or an<br> > extension to it. I think it would be clearer to make it a separate<br> > RSVP object, although in theory a PCN-ingress could work out that a<br= > > PCN CL Flow IDs object is included, by a calculation from the object<b= r> > length (because the base PCN object is always a fixed length).<br> > <br> > I don't see the point of the LENGTH field (for the number of flow ID<b= r> > objects), given RSVP gives the length of an object in octets, from<br> > which the number of flow ID objects can be derived (divide by 16 for<b= r> > IPv4 or divide by 40 for IPv6). Also RSVP objects have to align on 4<b= r> > octet boundaries.</p> <p> </p> <p>Georgios: Please note that the PCN CL Flow IDs object is considered to b= e a different PCN object, since its frequency and functionality is very muc= h different than the frequency and functionality of the other PCN objects. <br> Regarding the length, I do not understand the comment, since such length fi= eld is necessary, due to e.g., variable length of the object.</p> <p> </p> <p>> <br> > <br> > <br> > =3D=3DEditorial Nits=3D=3D<br> > <br> > Globally:<br> > s/In this document it is considered that.../<br> > /To comply with this specification.../</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Abstract:<br> > s/specifies the extensions to/<br> > /specifies extensions to/</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > 1. Intro<br> > s/collocated/<br> > /colocated/<br> > s/extensions to the Generic Aggregated RSVP [RFC4860] for the support = of/<br> > /extensions to Generic Aggregated RSVP [RFC4860] for support of/</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > OLD<br> > Furthermore, this document and according to [RFC4860], in absence of<b= r> > e2e RSVP flows, a variety of policies (not defined in this document)<b= r> > can be used at the Aggregator to set the DSCP of packets passing into<= br> > the aggregation region and how they are mapped onto generic aggregate<= br> > reservations. These policies are not described in this document but<br= > > are a matter of local configuration.<br> > NEW<br> > In a similar way to [RFC4860], the Aggregator can detect flows<br> > based on policy<br> > (not defined in this document) rather than using e2e RSVP flow<br> > signalling. Then<br> > it can map them onto aggregate reservations and set the DSCP of<br> > the packets of<br> > these flows as they pass into the aggregation region.</p> <p> </p> <p>Georgios: The above mentioned paragraph is deleted completely from the d= raft!</p> <p> </p> <p>> <br> > Section 1.1. Terminology<br> > <br> > " Ingress-egress-aggregate (IEA):<br> > [...]<br> > combination of (1) fields), (2) IP addresses of the<br> > "<br> > Some text appears to be missing here.<br> > <br> > Section 1.1. Terminology<br> > OLD:<br> > t-recvFail<br> > An ingress-egress-aggregate timer that is used at<br> > The Decision point (in this document at the PCN-<br> > ingress-node) which when expires raises an alarm to<br> > management, and activates the PCN-ingress-node to<br> > block the admission of new PCN-flows. This timer<br> > expires when it value is equal to T-fail and is<br> > reset when a report, i.e., RSVP aggregated RESV<br> > message, is received for a RSVP generic aggregated<br> > reservation (which is matched to one<br> > ingress-egress-aggregate).<br> > NEW:<br> > t-recvFail<br> > A timer per ingress-egress-aggregate that the<br> > PCN-ingress-node<br> > sets every time it receives an RSVP RESV message for that<br> > ingress-egress-aggregate. When its value reaches T-fail<br> > it is assumed that the PCN-ingress has lost<br> > contact with the<br> > PCN-egress. Therefore the PCN-ingress blocks<br> > admission of new<br> > PCN-flows into that aggregate and raises a<br> > management alarm.<br> > REASONING:<br> > The order in which the clauses were written made it hard to<br> > understand, there was nothing to say what it measured, and it wasn't<b= r> > clear what scope was implied by "it blocks PCN-flows".</p> <p> </p> <p>Georgios: Done! Please note that we also replaced =93RSVP RESV=94 with = =93RSVP Aggregated RESV=94.</p> <p> </p> <p>> <br> > Section 1.1 Terminology<br> > <br> > Underscores (e.g t_meas) are often used in the terminology section,<br= > > whereas hyphens (e.g. t-meas) are used in the body text.</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 2.1 Overview<br> > <br> > There is no Section 2.2, so all the sub-sections of 2.1.X could be pro= moted.</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 2.1.1<br> > s/used, SHOULD/used SHOULD/</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 2.1.2.<br> > OLD:<br> > The PCN-traffic is marked using PCN-marking and is classified using<br= > > The PCN-BA (i.e., combination of the DSCP and ECN fields).<br> > NEW:<br> > The PCN-ingress marks a PCN-BA useing PCN-marking (i.e.,<br> > combination of the DSCP and ECN fields), which interior nodes use to<b= r> > classify PCN-traffic.<br> > REASONING:<br> > Avoid passive verbs - ambiguous.</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 2.1.3<br> > s/for the determination of/to determine the address of/<br> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 2.1.4<br> > " o) PCN-ingress-node MUST use one or more policies to estimate w= hether<br> > an e2e RSVP reservation session associated with an e2e Path<br> > message that arrives at the external interface of the PCN-ingress-<br> > node can be mapped onto an existing RSVP generic aggregation<br> > reservation state.<br> > "<br> > This is a straightforward mapping function, it shouldn't involve polic= y.</p> <p>> Also mappings are deterministic - the word estimate is wrong.</p> <p> </p> <p>Georgios: We replaced the words =93to estimate=94 with =93to determine= =94</p> <p> </p> <p>> <br> > Section 3.1<br> > " o) If the timer t-recvFail expires [...]<br> > o) If the timer t-recvFail does NOT expire [...]<br> > "<br> > Switch the order of these two bullets, to describe the normal<br> > (successful) behaviour first.</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 3.1<br> > <br> > s/ingress-egress-aggregated/<br> > /ingress-egress-aggregate/<br> > s/then (1)/<br> > /(1)</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> [However, I suggest earlier that the technical sense should be<br> > substantially changed, possibly making these editorial changes irrelev= ant.]<br> > <br> > Section 3.8.<br> > OLD:<br> > The PCN object is specified in<br> > this document and is used for the report of the data measured by<br> > the PCN-egress-node, for a particular ingress-egress-aggregate,<br> > see [RFC6661], and [RFC6662].<br> > NEW:<br> > The PCN-egress-node reports the marking probabilities it measures for<= br> > a particular ingress-egress-aggregate in a PCN object, as specified in= <br> > Section 4 (see also [RFC6661], and [RFC6662]).<br> > REASONING:<br> > Poor sentence order.</p> <p> </p> <p>Georgios: Done! Re-edited!</p> <p> </p> <p>> <br> > Section 3.11.<br> > s/associated to one ingress-egress-aggregate/<br> > /associated with one ingress-egress-aggregate/</p> <p> </p> <p>Georgios: Done!</p> <p> </p> <p>> <br> > Section 3.15<br> > Repeats Section 2.1.9. Unnecessary.</p> <p> </p> <p>Georgios: The context of the two sections is slightly different! Therefo= re, I would like to leave them!</p> <p> </p> <p>> <br> > Section 4.<br> > s/by an PCN-egress node/<br> > /by a PCN-egress node/</p> <p> </p> <p>Georgios: Done! </p> <p> </p> <p>Best regards,<br> Georgios</p> <p> </p> <p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt"> </p> </span></font></div> </body> </html> --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36DE81EXMBX23adutwent_-- From wwwrun@rfc-editor.org Tue Mar 26 07:55:49 2013 Return-Path: <wwwrun@rfc-editor.org> X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7221F8B8D for <pcn@ietfa.amsl.com>; Tue, 26 Mar 2013 07:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.333 X-Spam-Level: X-Spam-Status: No, score=-101.333 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaRDjFzCoRO4 for <pcn@ietfa.amsl.com>; Tue, 26 Mar 2013 07:55:49 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 379FE21F8B7E for <pcn@ietf.org>; Tue, 26 Mar 2013 07:55:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1123372E14E; Tue, 26 Mar 2013 07:55:24 -0700 (PDT) To: philip.eardley@bt.com, martin.stiemerling@neclab.eu, sob@harvard.edu, slblake@petri-meat.com From: RFC Errata System <rfc-editor@rfc-editor.org> Message-Id: <20130326145524.1123372E14E@rfc-editor.org> Date: Tue, 26 Mar 2013 07:55:24 -0700 (PDT) Cc: pcn@ietf.org, michawe@ifi.uio.no, rfc-editor@rfc-editor.org Subject: [PCN] [Editorial Errata Reported] RFC5559 (3565) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list <pcn.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/pcn> List-Post: <mailto:pcn@ietf.org> List-Help: <mailto:pcn-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 Mar 2013 14:55:49 -0000 The following errata report has been submitted for RFC5559, "Pre-Congestion Notification (PCN) Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5559&eid=3565 -------------------------------------- Type: Editorial Reported by: Michael Welzl <michawe@ifi.uio.no> Section: 10.2 Original Text ------------- [Moncaster09-1] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", Work in Progress, May 2009. Corrected Text -------------- [Moncaster09-1] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5559 (draft-ietf-pcn-architecture-11) -------------------------------------- Title : Pre-Congestion Notification (PCN) Architecture Publication Date : June 2009 Author(s) : P. Eardley, Ed. Category : INFORMATIONAL Source : Congestion and Pre-Congestion Notification Area : Transport Stream : IETF Verifying Party : IESG