Subject: Re: [PCN] I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt

From: <[email-masked]>
Date: Sat, 10 Mar 2012 19:38:13 +0000

Hi all,

Please note that draft-ietf-tsvwg-rsvp-pcn-01.txt has just been posted.
The following modifications have been done, see Section 4 (introductory text) and section 4.1:

o) The CLE field has been removed from the PCN object format.

o) two new CL based PCN objects have been defined that can be used to carry the number of flow identifiers for individual flows within an ingress-egress-aggregate that have recently experienced  excess-marking, see also draft-ietf-pcn-signaling-requirements-08:

      o) Controlled (CL) PCN CL Flow IDs object, IPv4 addresses are used: 
          Class = PCN
          C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs

       o) Controlled (CL) PCN CL Flow IDs object, IPv6 addresses are used: 
            Class = PCN
             C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs

The main open issue, see also section 4 (introductory text)  that is related to one of the above listed modifications and needs to be discussed by the tsvwg WG is the following:

   There are at least two possible options of carrying the 
   PCN objects of C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or 
   RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs:
     o) Option 1: The PCN objects of C-Type: 
        RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or 
        RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by the 
        aggregated Resv message together with the other PCN object 
        C-Types. The advantage of this object is that no additional 
        message needs to be supported by this signaling protocol. The 
        drawback of this option is that the PCN objects of C-Type: RSVP-
        AGGREGATE-IPv4-PCN-CL-FLIDs or RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs 
        can become larger than the maximum transmission unit (MTU) along 
        a path to the Aggregator.

     o) Option 2: The PCN objects of C-Type:     
        RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or 
        RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by NOTIFY 
        messages, see [RFC3473]. In particular, the NOTIFY 
        <flow descriptor list> field could carry the flow IDs. The 
        advantage of this option is that the total list of the flow IDs 
        that need to be sent to the Aggregator can be divided in smaller 
        sets. Each of these sets can be then carried by one NOTIFY 
        message. The number of flow IDs that are included in such a set 
        MUST be such that the length of any NOTIFY message will not 
        become larger than the maximum transmission unit (MTU) along a 
        path to the Aggregator. The main disadvantage is the signaling 
        protocol needs to use an additional message type. If this option 
        is chosen then the format of the PCN objects of 
        C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or 
        RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs may need modifications. The 
        same holds for the procedures on handling the NOTIFY message by 
        the Interior nodes and by the Aggregator.

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens [email-masked] [[email-masked]]
Verzonden: zaterdag 10 maart 2012 20:12
Aan: [email-masked]
CC: [email-masked]
Onderwerp: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains
        Author(s)       : Georgios Karagiannis
                          Anurag Bhargava
        Filename        : draft-ietf-tsvwg-rsvp-pcn-01.txt
        Pages           : 26
        Date            : 2012-03-10

   This document specifies the extensions to the Generic Aggregated RSVP
   [RFC4860] for support of the PCN Controlled Load (CL) and Single
   Marking (SM) edge behaviors over a Diffserv cloud using Pre-
   Congestion Notification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-01.txt

---

From: Tom Taylor <[email-masked]>
Date: Sat, 10 Mar 2012 16:08:48 -0500

The CL edge behaviour draft allows implementations to keep the number of 
flow identifiers down to a reasonable size. I would therefore suggest no 
new message is needed to carry them.

---

From: <[email-masked]>
Date: Thu, 22 Mar 2012 11:47:37 +0000

Hi,

Sorry, I had some problems understanding the draft. I spent a couple of hours and basically couldn’t get a mental model what the mechanism is. is there a presentation that could help me understand?

Suggest you include a problem statement. Something similar to S1.1 of rfc3175 (RSVP reservation aggregation). From a PCN perspective, I don’t understand the purpose. Is it saving something (signalling?) that could be done in a less efficient way without this doc? Or achieving something impossible without it?

I don't understand why you build on 4860 (generic aggregate reservations) rather than 3175 (aggregate reservations)

It would be helpful to outline the overall architecture. Fig 1 helps a bit, but I think it would be very useful to give examples of signalling for the basic cases (I roughly guess these are when there are e2e rsvp msgs for a new flow and [1] there is already PCN-state for the relevant pair of PCN-boundary-nodes; [2] when there isn't.) That would help show how PCN, RSVP and generic aggregated rsvp fit together. I didn't understand how (at what point in your procedure) the PCN-ingress-node knows which is the relevant PCN-egress-node
 
It is quite hard to work out at various points whether address means the end host or the PCN-boundary-node address. 

I found the last paras on page 9 & 10 not understandable (many-to-1 mapping of what-to-what?). Note that ingress-egress-aggregate is "the collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes" and some of the text seemed to contradict this definition. I think you mean: "between a particular pair of PCN-boundary-nodes there MAY be several generic aggregate reservations"? (I don't really understand why you might want that)

2.1.1 "The PHB-ID (Per Hop Behavior Identification Code) used, SHOULD be set equal to PCN-compatible Diffserv codepoint(s)." - aren’t they different lengths? 

I think [draft-ietf-pcn-signaling-requirements-08], [RFC5670] and [RFC5696] are probably Informative refs (rather than normative), and perhaps [RFC5559] is Normative rather than Informative.

If you have time, it would be good to find a corner in Paris so you can explain it to me - thanks!

Best wishes
phil

---

From: <[email-masked]>
Date: Thu, 22 Mar 2012 12:07:54 +0000

Hi Phil,

I think that some of your comments/questions can be answered by the slides that 
were presented during IETF 81 in Quebec city, see below, where the initial version of the draft had been presented, at both tsvwg and pcn wg meetings:

http://www.ietf.org/proceedings/81/slides/pcn-0.pdf

http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens [email-masked] [[email-masked]]
Verzonden: donderdag 22 maart 2012 12:47
Aan: [email-masked]; [email-masked]
Onderwerp: RE: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt

Hi,

Best wishes
phil