Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
Bob Briscoe <bob.briscoe@bt.com> Fri, 16 November 2012 20:14 UTC
Return-Path: <bob.briscoe@bt.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A19121F86DB for <tsvwg@ietfa.amsl.com>; Fri, 16 Nov 2012 12:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level:
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp5E0G1KU-mP for <tsvwg@ietfa.amsl.com>; Fri, 16 Nov 2012 12:14:47 -0800 (PST)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B521F85DF for <tsvwg@ietf.org>; Fri, 16 Nov 2012 12:14:46 -0800 (PST)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:14:44 +0000
Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:14:41 +0000
Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Fri, 16 Nov 2012 20:14:39 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353096877994; Fri, 16 Nov 2012 20:14:37 +0000
Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAGKEYxK014300; Fri, 16 Nov 2012 20:14:34 GMT
Message-ID: <201211162014.qAGKEYxK014300@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 16 Nov 2012 20:14:33 +0000
To: karagian@cs.utwente.nl
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl>
References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_774171199==.ALT"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, slblake@petri-meat.com, philip.eardley@bt.com, anuragb@cisco.com, sob@harvard.edu, rsvp-dir@ietfa.amsl.com, pcn@ietf.org, jmpolk@cisco.com
Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Nov 2012 20:14:50 -0000
Georgios, Yes, I apologise for not reviewing earlier. I appreciate you followed the procedure. My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to understand it. So I stayed quiet even though I wasn't so happy about the direction, because I didn't have enough understanding to feel I could argue. Only in the last week or so, I collected together all the references and re-read them and their references, and made a concerted effort to understand what your draft was proposing. I have to say, it was quite a struggle (over a few days and the write-up took 2 days). However, I admit that it would have been preferable for everyone if I had made this effort earlier. Bob At 13:02 16/11/2012, karagian@cs.utwente.nl wrote: >Hi Bob, > >$B!!(B > >Thanks for your comments! > >Regarding your statement: What I meant in my previous email is that >our individual draft that was used as a working basis for this WG >draft was already using the generic aggregation RSVP (RFC 4860) as >the existing signaling protocol, see: > > > ><http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt>http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt > > > >Moreover, during IETF 81, this individual draft has been presneted, >where also the rationale of using (RFC 4860) was also the following >slides see presentation slides (slide 5): > > > >http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf > >$B!!(B > >In particular in slide 4 mentions: > >"All PCN charter items are fulfilled, except: > >Submit Encoding and Transport of PCN from Domain Egress to Ingress >to the IESG for consideration as a Proposed Standard RFC > >Pairs of PCN edge nodes use ingress-egress-aggregates (IEA): > >Need a signaling protocol to transport PCN information from >PCN-egress-node to PCN-ingress-node and to maintain >ingress-egress-aggregate between each pair of PCN edge nodes" > >Furthermore Slide 5 mentions: > >$B!!(B > >"IETF QoS signaling protocols to solve problem: > >Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979) > >Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) > >Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860) > >All can be used, but for time being selected RFC 4860 due: > >possible deployment interest > >supports RFC 3175 and additional features such as: > >support of multiple IEAs from same pair of PCN edge nodes > >support of bandwidth reduction for individual flows (RFC 4495)" > >$B!!(B > >Before IETF 81 and during IETF 81 this point has been discussed. > >The outcome of these discussions is that short after IETF 81, the >individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) > >become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, >which also was using RFC 4860 as the base signaling protocol. > >$B!!(B > >It will be very helpful if the PCN WG chairs (Scott and/or Steve) >and the tsvwg WG chairs (Gorry and/or James) could confirm the above statement! > >$B!!(B > >So both the PCN WG and tsvwg WG agreed that this specifictaion >should use as basis the generic RSVP aggregation protocol! > >$B!!(B > >$B!!(B > >$B!!(B > >In a subsequent email and on a later moment I will also answer to >your further remarks! > >$B!!(B > >Best regards, > >Georgios > >---------- >Van: Bob Briscoe [bob.briscoe@bt.com] >Verzonden: donderdag 15 november 2012 14:07 >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-dir@ietfa.amsl.com >Onderwerp: 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 based. > >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 >signalling 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 >their 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. > >{Note 1: except in one case described later - but it doesn't require >all the other baggage of aggregate reservations} > >==Background== >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]. > >In contrast, as you correctly point out (in Section 2.1.7), PCN >requires absolutely no reservation-related state on interior nodes. > >==Disadvantages== >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-nodes (if this isn't obvious, I spell it out >separately for PATH & RESV messages below). > >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.) > >3) Extra Latency >A further disadvantage is the extra latency required for the first >reservation that sets up an aggregate. 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). 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. > >==PATH== > >With RFC 3175 or 4860 aggregate paths, the aggregator forwards the >e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the >deaggregator changes 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. > >==RESV== > >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. > >==PCN object== > >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 >marking probabilities, and PCN 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 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-ingress, so a PCN object can be included in each of these. To >ensure that PCN objects are sent often enough, I suggest the >PCN-egress also maintains a timer per 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 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 message would need to somehow tell the ingress not >to forward 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 knows not to forward the RESV refresh further. > >The wire protocol doesn't need to identify whether the SESSION is an >aggregate or not. This is the one case I mentioned at the start >{Note 1} where an aggregate is referred to on the wire. > > > >In summary, PCN already reduces reservation state and processing to >nothing on interior nodes. Adding aggregate reservations to PCN >requires more processing and state, it unnecessarily pins routes to >interior nodes and adds unnecessary latency. > > >Bob > >At 18:23 14/11/2012, karagian@cs.utwente.nl wrote: >>Hi Bob, >> >>Regarding the generic aggregated RSVP selection, actually the PCN >>WG agreed with this selection! >>This was actually the first step that was needed for this work, and >>the PCN WG had no main objections on this selection! >> >>So I do not understand your remark that your comment will have >>major implications! >> >>Please note that the generic aggregated RSVP is selected since the >>PCN IEA are associated with flows that are aggregated at the edges. >>So a signalling protocol that supports aggregation of flows at the >>edges is very suitable for this purpose! The generic aggregated >>RSVP is such a signalling protocol! >> >> >>Best regards, >>Georgios >> >> >> >> >>From: Bob Briscoe [<mailto:bob.briscoe@bt.com>mailto:bob.briscoe@bt.com] >>Sent: woensdag 14 november 2012 12:57 >>To: Anurag Bhargava (anuragb) >>Cc: Karagiannis, G. (EWI) >>Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >> >>Anurag, >> >>I have my comments half-written up. I will try to finish them by >>the end of today. >> >>They should be orthogonal to the PBAC comment below, so if you >>wanted to start altering that area, I don't think it would waste >>too much time. >> >>However, my main comments will concern the use of aggregated >>reservations (as I said at the mic), so that could have major implications. >> >> >>Bob >> >>At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote: >> >>Hi Bob, >> Thanks for the comments. If U have some text that will be great >> els I have also started putting some text on the topic U brought up. >> May be we can conference after US thanksgiving week and >> collaborate the text and try to move forward. >> >> Please let us know what might be a good time and I can schedule a >> Webex conf. >> >>Thx >>-Anurag >> >>From: "<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl " >><<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl > >>Date: Saturday, November 10, 2012 8:10 AM >>To: "<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com" >><<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> >>Cc: "<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk" >><<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk>, Anurag Bhargava >><<mailto:anuragb@cisco.com>anuragb@cisco.com>, >>"<mailto:tsvwg@ietf.org>tsvwg@ietf.org" >><<mailto:tsvwg@ietf.org>tsvwg@ietf.org>, >>"<mailto:philip.eardley@bt.com>philip.eardley@bt.com " >><<mailto:philip.eardley@bt.com>philip.eardley@bt.com > >>Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >> >>Hi Bob, >> >> >> >>Thanks very much for the comments! I think that they are very useful! >> >> >> >>It will be very beneficiary for the fast progress of this draft if >>you would like to contribute as a co-author to this draft and write >>this additional section that describes "that the PCN-ingress can >>refer flow admission and >>termination decisions to a central decision point (using e.g. >>COPS), which will respond to the PCN-ingress as per RFC2753. >>(Alternatively the PCN-ingress could itself be the policy decision point.)" >> >> >> >>Best regards, >> >>Georgios >> >> >> >>---------- >>Van: Bob Briscoe [<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com] >>Verzonden: vrijdag 9 november 2012 16:33 >>To: Karagiannis, G. (EWI) >>Cc: <mailto:carlberg@g11.org.uk>carlberg@g11.org.uk; >><mailto:anuragb@cisco.com>anuragb@cisco.com; >><mailto:tsvwg@ietf.org>tsvwg@ietf.org; EARDLEY, Phil >>Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 >> >>Georgios, >> >>I shall post my full review of this draft in the next few days (needs >>typing up - currently scribbled on a paper copy). This email is >>solely in response to your answer about on-path vs off-path policy. >> >>At 18:55 04/11/2012, >><mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl wrote: >> >So in this case an additional signaling protocol will be >> >needed to be specified that covers the signaling between the >> >PCN-egress-node and the centralized node >> >and between PCN-ingress-node and the centralized node. >> >In PCN we decdided to only focus on the specification of the >> >signaling protocol that completes the >> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus >> >on the signaling protocol >> >used between the edge nodes and the centralized node. >> >>When I/we originally designed CL-PCN over RSVP (2005), the idea was >>that it would fit with the policy-based admission control (PBAC) >>architecture of RFC2753. In this architecture, an Intserv node at the >>ingress to a domain is the policy enforcement point (PEP), and it >>refers to a logically centralised 'policy decision point' (PDP) for >>decisions on which flows to block/terminate, typically using COPS. >> >>To make this doc fit the PBAC framework, all we have to do is: >>* Describe the PCN-ingress only as the PCN-ingress and not as the >>decision point (find 'decision' throughout doc and fix). >>* Add a section saying the PCN-ingress can refer flow admission and >>termination decisions to a central decision point (using e.g. COPS), >>which will respond to the PCN-ingress as per RFC2753. (Alternatively >>the PCN-ingress could itself be the policy decision point.) >>* Refer to this new PBAC section from Section 3.11 giving the >>admission decision procedure. >> >>* Some people might think this means COPS will need new protocol >>elements to carry PCN marking rates to the policy decision point. But >>PCN marking rates are irrelevant to the policy decision: the >>PCN-ingress just uses PCN to determine whether it needs to block or >>terminate, and it refers to the policy decision point for which flows >>to block/terminate. >> >>* Unfortunately, neither of the two PCN system descriptions [RFC6661, >>RFC6662] describe a PBAC-based case. The architecture [RFC5559] >>refers to the PBAC framework [RFC2753] but unfortunately doesn't >>spell out how it fits. Originally, I referenced PBAC from RFC5559, >>but just as the PCN w-g was closing I realised that (some?) others in >>the PCN w-g were working under the assumption that the only way to >>talk to a centralised policy node was from the egress, possibly >>without being aware of the contents of RFC2753. >> >>I think it's OK to introduce a new architectural arrangement in this >>RSVP doc, given RFC2753 is specific to the way RSVP works. >> >> >>Bob >> >> >> >>At 12:28 05/11/2012, >><mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl wrote: >> >Hi Ken, >> > >> >Thank you very much! >> >We will try to catch Francois and discuss the last (in line) >> issue with him! >> > >> >Best regards, >> >Georgios >> > >> >________________________________________ >> >Van: ken carlberg [<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk] >> >Verzonden: maandag 5 november 2012 13:23 >> >To: Karagiannis, G. (EWI) >> >Cc: <mailto:tsvwg@ietf.org>tsvwg@ietf.org; >> <mailto:anuragb@cisco.com>anuragb@cisco.com >> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03 >> > >> >Georgios, >> > >> > > Georgios: We will try to explain the rationale of why we consider >> > that RSVP can only be used for the situation that the >> > > decision point is collocated with the PCN-ingress-node. The main >> > reason of this is that in the case that the >> > > decision point is collocated with the PCN-ingress-node,the >> > required signaling protocol used to complete a >> > > feedback loop from egress to ingress can be an entirely on-path >> > protocol, like what RSVP is. >> > > In the situation that the the decision point is a centralized >> > node, then the required signaling protocol >> > > can be a combination of an on-path and off-path protocol. This is >> > because the >> > > decision point might not be located on the data path! So in this >> > case an additional signaling protocol will be >> > > needed to be specified that covers the signaling between the >> > PCN-egress-node and the centralized node >> > > and between PCN-ingress-node and the centralized node. >> > > In PCN we decdided to only focus on the specification of the >> > signaling protocol that completes the >> > > feedback loop from PCN-egress-node to PCN-ingress-node and to >> > focus on the signaling protocol >> > > used between the edge nodes and the centralized node. >> > > This is also the reason of why PCN WG decided to only focus on >> > the situation that the decision point is >> > > collocated with the PCN-ingress-node. >> > >> >Great, this is helpful, and this is the information that needs to be >> >in the draft. >> > >> > >> 6) This comment is just for you to contemplate -- I'm not >> > expecting any changes. >> > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs. >> > >> And it seems a lot of this is a carry over from rfc-4860, so in >> > a sense you are inheriting an approach that >> > >> was agreed to from an earlier effort. But I wonder in the back >> > of my mind, what impact occurs if >> > >> an implementor doesn't follow the SHOULD? Does the design break >> > in supporting PCN? >> > >> Again, I want to stress that this isnt a show stopper, but I >> > would appreciate it if you gave it some thought. >> > > >> > > Georgios: Yes, in several cases the design might break in >> supporting PCN. >> > > This is also the reason of using SHOULD instead of MAY. Do you >> > want us to explain this in more detail in the draft? >> > >> >well, actually, I was more curious as to why a number of these cases >> >are SHOULD instead of MUST. Again, the SHOULD's in your document >> >seem to be a carry-over from rfc-4860 (which set the precedent), so >> >its a bit unfair for you to explain what was done in an earlier >> >effort. I just wanted to make sure you gave some thought to the >> >subject. And if things will break if SHOULD is not followed by an >> >implementer/configuration, then maybe you should be more stringent >> >and change things to MUST. Perhaps a brief private conversation >> >with Francois Le Faucheur will be helpful. >> > >> >cheers, >> > >> >-ken >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 karagian
- [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 ken carlberg
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Anurag Bhargava (anuragb)
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 ken carlberg
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 karagian
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Bob Briscoe
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 karagian
- [tsvwg] Redundant aggregate reservations: draft-i… Bob Briscoe
- Re: [tsvwg] [PCN] Redundant aggregate reservation… Bob Briscoe
- Re: [tsvwg] Redundant aggregate reservations: dra… karagian
- Re: [tsvwg] [PCN] Redundant aggregate reservation… Bob Briscoe
- Re: [tsvwg] Redundant aggregate reservations: dra… Bob Briscoe
- Re: [tsvwg] [PCN] Redundant aggregate reservation… karagian
- Re: [tsvwg] Redundant aggregate reservations: dra… karagian
- Re: [tsvwg] [PCN] Redundant aggregate reservation… Bob Briscoe
- Re: [tsvwg] [PCN] Redundant aggregate reservation… Bob Briscoe
- Re: [tsvwg] Redundant aggregate reservations: dra… Bob Briscoe
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 Anurag Bhargava (anuragb)
- Re: [tsvwg] [PCN] Redundant aggregate reservation… Tom Taylor
- Re: [tsvwg] [PCN] Redundant aggregate reservation… Tom Taylor
- Re: [tsvwg] [PCN] Redundant aggregate reservation… Tom Taylor
- Re: [tsvwg] Redundant aggregate reservations: dra… Francois Le Faucheur (flefauch)
- Re: [tsvwg] Redundant aggregate reservations: dra… karagian
- Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03 karagian
- Re: [tsvwg] Redundant aggregate reservations: dra… karagian
- [tsvwg] RSVP PCN and PBAC Black, David
- Re: [tsvwg] RSVP PCN and PBAC karagian
- Re: [tsvwg] RSVP PCN and PBAC Black, David
- Re: [tsvwg] RSVP PCN and PBAC Anurag Bhargava
- Re: [tsvwg] RSVP PCN and PBAC Black, David