Re: [PCN] FW: RE: PCN encoding option

["Geib, Ruediger" <[e-mail]>]

Hi Toby,

I don't object to your position in general, my point of view is:

- no standardisation to avoid unplanned misconfiguartion.
- standardisation to avoid "planned misconfiguration" (misuse).
- standardisation to tackle with different interpretation of 
  the same bits by different domains (see eg. DiffServ).
- description of misconfiguration scenarios and how to deal 
  with them in appropriate sections of a standard (sometimes 
  this is security, sometimes operation).

Otherwise, I welcome every PCN solution starting with single 
marking and evolving to more complex schemes. The main argument 
I see for such an approach is applicability within MPLS domains 
by support of a single codepoint mechanism. I also regard 
support of a single codepoint mechanism as a "MUST" for every 
PCN solution searching deployment in the backbone (of the company 
I work for, to state it correctly).

Regards,

Rudiger 

| -----Original Message-----
| From: [e-mail] [mailto:[e-mail]] 
| Sent: Tuesday, March 04, 2008 6:19 PM
| To: Geib, Rüdiger; [e-mail]; 
| [e-mail]
| Cc: [e-mail]
| Subject: RE: [PCN] FW: RE: PCN encoding option
| 
| I am happy to accept this as a view if that is what others 
| agree with. I am now becoming increasingly unclear as to what 
| we will need to actually do to ensure we are compliant with 
| RFC4774. The idea of my scheme is to allow for possible 
| leakage of packets into the non-PCN region. As Ruediger 
| correctly points out, strictly this is an operational issue 
| not a design issue. However I do think that we would need to 
| highlight the potential risks that exist if there is any 
| misconfiguration...
| 
| However I still like the extra flexibility that is offered by 
| my proposal. It seems to allow for incremental deployment 
| (start with single marking then add termination marking), it 
| allows extra codepoints for a possible future extension to an 
| end-to-end deployment and it seemed (when I wrote it) to 
| completely address all the concerns raised in RFC4774.
| 
| Toby
| ____________________________________________________________________
| Toby Moncaster, <[e-mail]> Networks Research 
| Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 
| 1473 648734 
| 
| 
| > -----Original Message-----
| > From: [e-mail] [mailto:[e-mail]] On 
| Behalf Of 
| > Geib, Ruediger
| > Sent: 03 March 2008 08:09
| > To: [e-mail]; [e-mail]
| > Cc: [e-mail]
| > Subject: Re: [PCN] FW: RE: PCN encoding option
| > 
| > Hi Joe, hi Michael,
| > 
| > I share you views and I'd like to repeat my point that 
| routers can be 
| > misconfigured in many ways and locations. This may end in undesired 
| > behaviour. I can't recall that its a task of 
| standardisation to deal 
| > with unplanned misconfigurations, it's rather a task of operation.
| > 
| > Regards,
| > 
| > Rudiger
| > 
| > | I agree with Michael's views. Two DSCP is high prices to pay to 
| > | address misconfiguration problem and only sometimes.
| > | 
| > | Regards, Joe
| > | email:[e-mail]
| > | Telephone:[phone]
| > | -----Original Message-----
| > | From: Michael Menth [mailto:[e-mail]]
| > | Sent: February 20, 2008 5:50 AM
| > | To: [e-mail]
| > | Cc: [e-mail]; [e-mail]; Chan, Kwok-Ho 
| (BL60:470); 
| > | Babiarz, Jozef (CAR:0S03); [e-mail]; 
| > | [e-mail]; [e-mail];
| > [e-mail]
| > | Subject: Re: FW: RE: PCN encoding option
| > | 
| > | Hi Toby,
| > | 
| > | as I understand the proposal, the motivation is to avoid 01/10 
| > | codepoints as it is not good if they leak out of the 
| network since 
| > | 01/10
| > | 
| > | is interpreted as ECN-capable ECT(0/1) by ECN nodes. 
| However, there 
| > | is the same problem with 11 marking, i.e. 11-packets may not be 
| > | dropped by ECN nodes outside the PCN domain although 
| endpoints are 
| > | not ECN capable.
| > | 
| > | Even if 11-packets trigger flow termination, it is not guaranteed 
| > | that exactly the marked flow going over an overloaded ECN node is 
| > | terminated.
| > | 
| > | Just want to say that this solution wants to solve a problem that 
| > | exists
| > | 
| > | only in case of misconfiguration (leaking packets), but does not 
| > | fully achieve that objective. Therefore, I feel that spending two 
| > | DSCP values is quite expensive.
| > | 
| > | Regards,
| > | 
| > |     Michael
| > | 
| > | [e-mail] wrote:
| > | >  
| > | > All,
| > | >  
| > | > Phil and I have just been discussing the encoding draft
| > and feel we
| > | may
| > | > have lit upon a neat solution that seems to have lots of
| > | pros and few
| > | > cons... In order to get a better feeling for this proposal
| > | I will go
| > | > through the simplified version without Affected marking first:
| > | >
| > | > PCN Meaning		ECN 	 DSCP
| > | >
| > | > PCN capable		00	 PCN 1
| > | > Admission Mark	11	 PCN 1
| > | > Termination Mark	11/00	 PCN 2
| > | >
| > | > PCN 1 and PCN 2 are 2 different codepoints with the same
| > | PCN behaviour
| > | > aggregate.
| > | >
| > | > Pros:
| > | >  o  Termination marking and admission marking are 
| independent, eg 
| > | > termination marking can be done after a packet has been 
| admission 
| > | > marked. Therefore a router can write AM or TM without
| > having to read
| > | the
| > | > packet's PCN marking first, which is easier to implement. (Note:
| > | > Over-writing a TM with AM is not allowed for 3SM & CL, see
| > | > draft-charny-pcn-comparison.)
| > | >
| > | > o  This scheme avoids giving semantics to ECT(0) and
| > | ECT(1). This is
| > | > safest option if packets leak outside the PCN region, due
| > | to some fort
| > | > of misconfiguration of the PCN-boundary-nodes (relevant for
| > | a single
| > | > domain deployment of PCN).
| > | >
| > | > o  It leaves open the possibility of using ECT(0) and
| > | ECT(1) in some
| > | > mysterious way in a future end-to-end PCN deployment
| > | >
| > | > o  For a router to classify a packet as PCN, it simply
| > | reads its DSCP.
| > | > This is probably easier than checking both its DSCP & 
| ECN fields. 
| > | >
| > | > o  Incremental deployment steps are possible [1] could 
| deploy SM 
| > | > initially and later AM/TM. Just add the second
| > | DSCP.
| > | > If a router isn't upgraded at the same time nothing too 
| horrific 
| > | > happens.
| > | > [2] could just deploy admission control & add termination
| > | later, just
| > | by
| > | > adding a new DSCP; there is no need to change the
| > encoding and check
| > | for
| > | > backwards compatibility? Vice-versa is also ok?
| > | >
| > | > Cons:
| > | > o  It needs an extra DSCP, per PCN behaviour aggregate. 
| (Although 
| > | > possibly it's OK to use the same DSCP for TM for all PCN BAs?)
| > | >
| > | > o  If a packet (in a PCN flow) arrives at the egress with
| > | its ECN = 11
| > | > and it really is required to preserve this info across the
| > | PCN-domain,
| > | > then some complexity is needed at the PCN-boundary-nodes
| > | (tunnelling)
| > | >
| > | > o  If the PCN-domain is operating multipath routing
| > (ECMP) that uses
| > | the
| > | > DSCP to select routes, then there may be mis-ordering of packets
| > | within
| > | > a flow. This may be OK as (1) no-one has yet said they know
| > | of an ECMP
| > | > algorithm that in practie uses the DSCP; (2) a risk of
| > mis-ordering
| > | when
| > | > there is termination marking may be acceptable
| > | >
| > | > If Affected marking is needed then the scheme can be modified as
| > | > follows:
| > | >
| > | > PCN Meaning		ECN 	DSCP
| > | >
| > | > PCN capable		00	PCN 1
| > | > Admission Mark	11	PCN 1
| > | > Termination Mark	11	PCN 2
| > | > Affected Mark	00	PCN 2
| > | >
| > | > The pros for this scheme are broadly similar to the 
| above. However
| > | there
| > | > is a new con which may or may not matter: If a packet 
| is affected
| > | marked
| > | > and a later node is doing admission marking then it will
| > reset the
| > | > affected mark to a termination mark. Work would be needed
| > to see if
| > | this
| > | > skews the results and causes significant 
| over-termination or not.
| > | >
| > | > Please could people look through this scheme and highlight any 
| > | > additional concerns that they may have (and extra 
| benefits too). I
| > | would
| > | > like to get as many opinions as possible. 
| > | >
| > | > What I want to avoid is people just emailing back with
| > "why not try
| > | this
| > | > scheme instead". Currently we seem to have a plethora 
| of possible 
| > | > schemes on the table and people need to start putting down much
| > | clearer
| > | > pros and cons for the schemes they support... So it could
| > | be good to
| > | > have a similar "one page" email about a specific scheme
| > | that only uses
| > | > one DSCP for PCN, but uses the 01/10 codepoints instead.
| > | >
| > | > Toby
| > | > 
| > ____________________________________________________________________
| > | > Toby Moncaster, <[e-mail]> Networks Research
| > | Centre, BT
| > | > B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone]
| > | >   
| > | 
| > | --
| > | Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
| > | Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
| > | Germany, room B206
| > | phone: [phone], fax: [phone] 
| > | mailto:[e-mail]
| > | http://www3.informatik.uni-wuerzburg.de/research/ngn
| > | 
| > | _______________________________________________
| > | PCN mailing list
| > | [e-mail]
| > | https://www.ietf.org/mailman/listinfo/pcn
| > | 
| > _______________________________________________
| > PCN mailing list
| > [e-mail]
| > https://www.ietf.org/mailman/listinfo/pcn
| > 
| 
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn