[rsvp-dir] Fwd: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

[Bob Briscoe <[e-mail]>]

For the record, the posting below is blocked awaiting moderator 
approval due to too many recipients. I am re-sending just to the 
RSVP-DIR list that raised the objection. In future I'll cut the distr.


Bob

>Date: Tue, 20 Nov 2012 21:29:26 +0000
>To: <[e-mail]>
>From: Bob Briscoe <[e-mail]>
>Subject: RE: Redundant aggregate reservations:  draft-ietf-tsvwg-rsvp-pcn-03
>Cc: <[e-mail]>, <[e-mail]>, 
><[e-mail]>, <[e-mail]>, <[e-mail]>, 
><[e-mail]>, <[e-mail]>, <[e-mail]>, 
><[e-mail]>, <[e-mail]>
>
>Georgios,
>
>See other email. Pls focus on the specifics (you will need to go 
>back to my original email in the thread, because the specifics were 
>immediately cut from the thread when Tom understood them).
>
>The IETF can choose to continue along a path that it originally 
>agreed, whether right or wrong, but it is important to discuss 
>whether it is right or wrong first.
>
>
>Bob
>
>At 10:29 17/11/2012, [e-mail] wrote:
>
>>Hi Bob,
>>
>>
>>
>>So, what you actually proposing is to discard a specification that 
>>has been accepted by both PCN and tsvwg WGs to be considered as a 
>>WG specification and to use a specification that you are proposing 
>>and that is conceptually and architecturally wrong.
>>
>>
>>
>>The solution that you are proposing, i.e., use of the e2e RSVP 
>>(RFC2205), is in my opinion architecturally and conceptually wrong!
>>
>>The reason is the following!
>>
>>
>>
>>In PCN we need a signaling protocol that is able to: (1) to carry 
>>information from PCN-egress-edge to PCN-ingress-edge and (2) the 
>>carried information needs to be related to an aggregated state, 
>>i.e., the ingress-egress-aggregate state.
>>
>>The e2e RSVP (RFC2205) can only support requirement (1), but is not 
>>able to support (2), since the e2e RSVP carries information that is 
>>associated with a per flow state maintained at the edges.
>>
>>Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can 
>>support both requirements, since one of the features that are 
>>supported by both is to carry objects that are associated to an 
>>aggregated state maintained at the edges. In the context of PCN, 
>>the aggregated state is the ingress egress aggregate state.
>>
>>
>>
>>Best regards,
>>
>>Georgios
>>
>>
>>----------
>>Van: Bob Briscoe [[e-mail]]
>>Verzonden: vrijdag 16 november 2012 21:14
>>To: Karagiannis, G. (EWI)
>>Cc: [e-mail]; [e-mail]; [e-mail]; 
>>[e-mail]; [e-mail]; [e-mail]; 
>>[e-mail]; [e-mail]; [e-mail]; 
>>[e-mail]
>>Onderwerp: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
>>
>>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, [e-mail] 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>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 [[e-mail]]
>>>Verzonden: donderdag 15 november 2012 14:07
>>>To: Karagiannis, G. (EWI); [e-mail]
>>>Cc: [e-mail]; [e-mail]; [e-mail]; 
>>>[e-mail]; PCN IETF list; [e-mail]
>>>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, [e-mail] 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:[e-mail]>mailto:[e-mail]]
>>>>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:[e-mail]>[e-mail] " 
>>>><<mailto:[e-mail]>[e-mail] >
>>>>Date: Saturday, November 10, 2012 8:10 AM
>>>>To: "<mailto:[e-mail]>[e-mail]" 
>>>><<mailto:[e-mail]>[e-mail]>
>>>>Cc: "<mailto:[e-mail]>[e-mail]" 
>>>><<mailto:[e-mail]>[e-mail]>, Anurag 
>>>>Bhargava <<mailto:[e-mail]>[e-mail]>, 
>>>>"<mailto:[e-mail]>[e-mail]" 
>>>><<mailto:[e-mail]>[e-mail]>, 
>>>>"<mailto:[e-mail]>[e-mail] " 
>>>><<mailto:[e-mail]>[e-mail] >
>>>>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:[e-mail]>[e-mail]]
>>>>Verzonden: vrijdag 9 november 2012 16:33
>>>>To: Karagiannis, G. (EWI)
>>>>Cc: <mailto:[e-mail]>[e-mail]; 
>>>><mailto:[e-mail]>[e-mail]; 
>>>><mailto:[e-mail]>[e-mail]; 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:[e-mail]>[e-mail] 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:[e-mail]>[e-mail] 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:[e-mail]>[e-mail]]
>>>> >Verzonden: maandag 5 november 2012 13:23
>>>> >To: Karagiannis, G. (EWI)
>>>> >Cc: <mailto:[e-mail]>[e-mail]; 
>>>> <mailto:[e-mail]>[e-mail]
>>>> >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
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design