Congestion and Pre-Congestion Notification WG (pcn) MONDAY, July 25, 2011 1510-1610 Afternoon Session II IETF 81 Meeting Agenda Chairs: Scott Bradner Steven Blake (Absent) Minutes by Cyndi Mills and Gorry Fairhurst o Agenda Agenda was bashed there were no changes. o Administrivia The datse for old milestones has been updated. Dave Harrington Area Director what should the transport be from the edge to the center? needs some updates? edge-behavior Propose change WG due dates to now with Briscoe's 3-in-1 o Generic Aggregation of RSVP over PCN Domains draft-karagiannis-pcn-tsvwg-rsvp-pcn-01 George Karagiannis generic aggregated RSVP suggesting augmentations to PCN SM and CL edge behavior drafts need a signalling protocol to transport PCN information from PCN-egress noted to PCN-ingress-node maintain ingress-egress-aggregate between each pair of PCN edge nodes possible solutions: (*) next steps in signaling protocol (NSIS) subset rfc 5971, 5974, 5974 (*) RFC3175 aggregation of RSVP for IPv4 nd IPv5 (*) RFC 4860 Generic Selected 4860, supports RFC3175, multiple IEAs from same pair of PCN edge nodes support of bandwidth reduction for individual flows (RFC 4495) Ken Clavert: Is the RSVP signaling going the same way as the PCN information. George: Assume the aggregation status is in place at the Egress, the state will be configured according to what would be defined in the PCN WG. Four new objects to be specified, and policies to be supported. Philip Eardley: What are the 2 objects for the CL-case. George: This is related to the rate of the non-marked, excess-marked, etc as mentioned in the signaling requirements draft. Philip: As I recall, the signaling is sent periodically, is this the case for RSVP? Scott: The Path message is sent periodically. Ken: This is a new reservation from an egress node, rather than aggregating upstream messages? George: An ingress-egress aggregate is established. The state is refreshed. the RESV messages include these new objects. Philip: How is the refresh period set? Francois: RSVP refreshes state, so it sends regular messages - but can send at any time, this is what is needed allowing RSVP to send additional RESV messages triggered. The refresh machinery will not normally be used (this is to maintain the state). Scott: must use existing mechanism for refresh state Francois: If you are not using RSVP in the core, then you could just use a PATH message, and use a NOTIFY message to signal the ingress edge state. George: Can you just send NOTIFY messages? Francois: I should check. Scott: Let's discuss this on the mailing list. Bob: Do you mean priority or existing policies. George: Not priority. On aggregation of messages Scott: The previous hop of the egress is then the ingress? George: Yes. Where should this work be done? Dave Harrington, AD: This work should be done in ¶ standardization of RSVP extensions goes through TSVWG Francois: There is work already on how this sort of thing is done already exists in PCN. Scott: What is actually needed to progress this, what needs to be changed in this draft? With the help of experts we can enhance existing functionality. Scott: Georgios, will talk to TSVWG about this right? Georgios: yes. Scott: Is this approach, is using RSVP a reasonable approach. This is a good approach. - 8 people No people against, Dave: What does the TSVWG chair think about taking this to TSVWG rather than here? Gorry: I think TSVWG would look favourably on work that came from a WG where there is significant support and interest in seeing this progressed. We'd have to see what the WG says on Friday, and see if they see issues. Scott: After the meeting we should be able to judge the right place to do this. Gorry: This works for me. I'd be happy to report on the energy and need of this WG to tsvwg. o Resolving issues with CL and SM Edge Behaviour Drafts draft-ietf-pcn-cl-edge-behaviour-09 draft-ietf-pcn-sm-edge-behaviour-06 Tina Tsou Question: What's the problem and the protocol solution? Philip: there wasn't enough about O&M, CL and S describe abstract protocol needs -- what should be communicated, but no concrete protocol proposal, want to see actual fields and protocol definition. Scott: Tom wants to know what is needed in these documents. Dave: Proper O&M discussion would help. You can submit the CL and SM documents, but not useful without protocol. o Resolving Issues with 3-in-1 Encoding Draft draft-ietf-pcn-3-in-1-encoding-05 BoB Briscoe decided to obsolete the old one (RFC5696) and use this rewritten document only, so you don't have to read both documents. superset of SM in baseline, but threshold marker cannot set 11 could not also accommodate PSDN. Immediate intent: summarize ML discussions, another wglc, 06bis written 3-in-1 is now a superset of 3-in-1 and single marking in baseline Cannot use pre-RFC6040 tunnels. added a section on backward compatibility. case: where only one marking function throughput PCN domain y excess traffic marking straightforward only threshold marking - issues with pre 6040 tunnels PSDM too different, continue on experimental track as alliterate to 3-in-1 Bob: Should we do it on its own? Scott: The cleanest solution was to do this on its own. Scott: Any comments on this draft? George: I think the draft specifies the mapping in a correct way. Scott: please submit document as soon as possible. o WG Status Discussion. WG Chair noted this was a well-attended meeting, and there was a potential charter modification that should be looked at. The group seemed to be completing its full set of documents. Are there strong feelings that there is additional work that the WG needs to do? Ken: When the group started it focused on one domain. First charter was in a single domain. Has anyone considered expanding to a multiple-domain? Scott: I do not recall discussion. Does anyone feel this is an important discussion? Bob: We did have a proposal that related to work combining CONEX and PCN. I think this is possible, but myself I do not necessarily see this is needed. Meeting closed at 16:05.