Subject: [tsvwg] main changes in draft-ietf-tsvwg-rsvp-pcn-02

From: <[email-masked]>
Date: Fri, 13 Jul 2012 06:14:04 +0000

Hi all,

The 02 version of the RSVP-PCN draft has been submitted last week to the IETF, see below:

http://www.ietf.org/id/draft-ietf-tsvwg-rsvp-pcn-02.txt

All comments received up to now are worked out!
The main changes compared to version 02 version are:

=> Main change 1: The draft is written in such a way that the following two assumptions do not anymore apply!

o) Assumption 1: More than one IEAs between same pair of PCN edge nodes should be supported, each of them using a different PHB-ID value
Why?: A requesting individual flow has a higher chance to be admitted to an IEA that is NOT in PCN-admission-state How? When IEA supported by a PCN-ingress-node is in PCN-admission state, then based on local policy, requesting e2e RSVP session (individual flow) should be either rejected or mapped to another IEA that is NOT in PCN-admission-state

In particular, the IEA definition used in PCN is not modified. Moreover each RSVP generic aggregated state is mapped/matched to only one IEA.

o) Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an individual flow without terminating the flow
Why?: flows will not be terminated unnecessary and at the same time the IEA bandwidth is reduced to solve the severe congestion
How?: When for IEA supported by PCN-ingress-node incoming traffic needs to be reduced then:
based on a local policy and for same IEA, selects a number of e2e RSVP sessions (individual flows) to be either terminated or reserved bandwidth of e2e RSVP sessions (individual flows) is reduced.

In particular, it is emphasized that the default manner of  how the IEA bandwidth is reduced during flow termination is based on the description given in the SM and CL edge behavior drafts.

=> Main change 2: The open issue given on page 18 in draft-ietf-tsvwg-rsvp-pcn-01 is removed. According to the discussion that we had on the mailing list, the First option was selected. 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.

=> Other changes: Terminology section is updated according to the last versions of SM and CL drafts.
Some editorials are fixed.

For more details on differences between draft-ietf-tsvwg-rsvp-pcn-01 and draft-ietf-tsvwg-rsvp-pcn-02,  please see:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rsvp-pcn-02

Comments are appreciated!

Best regards,
Georgios

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 23 Jul 2012 13:54:39 +0200

Hi Georgios,

More an editorial comment:
The IANA section isn't that useful for IANA, as it does not specify in 
which registry the code points should be registered and the information 
for IANA is distributed across the draft.

Here is my suggestion:
- Collect all relevant information, e.g., code points request and 
references to their defining sections, in the IANA considerations;
- point out in what registry the code points are to be entered;
- check what information is required to appropriately fill the 
particular registry.

Thanks in advance

   Martin

On 07/13/2012 08:14 AM, [email-masked] wrote:
> o) Assumption 1: More than one IEAs between same pair of PCN edge nodes
> should be supported, each of them using a different PHB-ID value
> Why?: A requesting individual flow has a higher chance to be admitted to
> an IEA that is NOT in PCN-admission-state How? When IEA supported by a
> PCN-ingress-node is in PCN-admission state, then based on local policy,
> requesting e2e RSVP session (individual flow) should be either rejected
> or mapped to another IEA that is NOT in PCN-admission-state
>
> In particular, the IEA definition used in PCN is not modified. Moreover
> each RSVP generic aggregated state is mapped/matched to only one IEA.
>
>
> o) Assumption 2: PCN-ingress-node should be able to reduce bandwidth of
> an individual flow without terminating the flow
> Why?: flows will not be terminated unnecessary and at the same time the
> IEA bandwidth is reduced to solve the severe congestion
> based on a local policy and for same IEA, selects a number of e2e RSVP
> sessions (individual flows) to be either terminated or reserved
> bandwidth of e2e RSVP sessions (individual flows) is reduced.
>
> In particular, it is emphasized that the default manner of  how the IEA
> bandwidth is reduced during flow termination is based on the description
> given in the SM and CL edge behavior drafts.
>
> => Main change 2: The open issue given on page 18 in
> draft-ietf-tsvwg-rsvp-pcn-01 is removed. According to the discussion
> that we had on the mailing list, the First option was selected. 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.
>
> For more details on differences between draft-ietf-tsvwg-rsvp-pcn-01 and
> draft-ietf-tsvwg-rsvp-pcn-02,  please see:
>
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>

-- 
[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: <[email-masked]>
Date: Mon, 23 Jul 2012 12:03:21 +0000

Hi Martin,

Thanks for the comments!

I will work out these comments in the following version of the draft!

Best regards,
Georgios

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: maandag 23 juli 2012 13:55
> To: Karagiannis, G. (EWI)
> Cc: [email-masked]
> Subject: Re: [PCN] main changes in draft-ietf-tsvwg-rsvp-pcn-02
> 
> Hi Georgios,
> 
> The IANA section isn't that useful for IANA, as it does not specify in which
> registry the code points should be registered and the information for IANA is
> distributed across the draft.
> 
> Here is my suggestion:
> - Collect all relevant information, e.g., code points request and references to
> their defining sections, in the IANA considerations;
> - check what information is required to appropriately fill the particular
> registry.
> 
> Thanks in advance
> 
>    Martin
> 
> > => Main change 1: The draft is written in such a way that the
> > following two assumptions do not anymore apply!
> >
> > o) Assumption 1: More than one IEAs between same pair of PCN edge
> > nodes should be supported, each of them using a different PHB-ID value
> > Why?: A requesting individual flow has a higher chance to be admitted
> > to an IEA that is NOT in PCN-admission-state How? When IEA supported
> > by a PCN-ingress-node is in PCN-admission state, then based on local
> > policy, requesting e2e RSVP session (individual flow) should be either
> > rejected or mapped to another IEA that is NOT in PCN-admission-state
> >
> > In particular, the IEA definition used in PCN is not modified.
> > Moreover each RSVP generic aggregated state is mapped/matched to only
> one IEA.
> >
> >
> > o) Assumption 2: PCN-ingress-node should be able to reduce bandwidth
> > of an individual flow without terminating the flow
> > Why?: flows will not be terminated unnecessary and at the same time
> > the IEA bandwidth is reduced to solve the severe congestion
> > In particular, it is emphasized that the default manner of  how the
> > IEA bandwidth is reduced during flow termination is based on the
> > description given in the SM and CL edge behavior drafts.
> >
> > that we had on the mailing list, the First option was selected. 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.
> >
> > For more details on differences between draft-ietf-tsvwg-rsvp-pcn-01
> > and draft-ietf-tsvwg-rsvp-pcn-02,  please see:
> >
> >
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in
> England 283