Subject: [re-ECN] ConEx and MPLS (Was Re: CONEX IESG comments #1 ([email-masked]))

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 16 Mar 2010 13:15:36 +0100

Hi

A question from a non-MPLS geek. 
What are the arguments against extending ConEx to MPLS?. 
I guess one obvious answer is the limited 3-bit field but are there more reasons against this?. 

My understanding is that the MPLS limitation is problematic only if one wish to ConEx-police traffic that comes from another ISP and that traffic is MPLS. 
It is still possible to do ConEx policing at the label edge routers. Of course the policing point will then not be at the border. 

Regards
Ingemar
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: den 16 mars 2010 11:24
> To: [email-masked]
> Subject: re-ECN Digest, Vol 13, Issue 45
> 
> If you have received this digest without all the individual 
> message attachments you will need to update your digest 
> options in your list subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> Click the 'Unsubscribe or edit options' button, log in, and 
> set "Get MIME or Plain Text Digests?" to MIME.  You can set 
> this option globally for all the list digests you receive at 
> this point.
> 
> 
> 
> Send re-ECN mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/re-ecn
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of re-ECN digest..."
> 
> 
> Today's Topics:
> 
>    1. Re:  CONEX IESG comments #2 ([email-masked])
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 16 Mar 2010 10:24:04 -0000
> From: <[email-masked]>
> Subject: Re: [re-ECN] CONEX IESG comments #2
> To: <[email-masked]>,	<[email-masked]>
> Message-ID:
> 	
> <[email-masked]
> .systemhost.net>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> In-line
> Best wishes
> phil
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Lars Eggert
> > Sent: 01 March 2010 15:34
> > To: [email-masked] list
> > Cc: The IESG
> > Subject: [re-ECN] CONEX IESG comments #2
> > 
> > 
> > Hi, CONEX group,
> > 
> > I'm going to forward a few issues that were raised during the IESG 
> > discussion of the charter to the list, and CC the IESG so that the 
> > discussion can happen directly, without me being the 
> bottleneck in the 
> > middle.
> > 
> > (I'd like to thank the ADs who wrote up their issues in this way - 
> > this will make it much easier to progress the discussion!)
> > 
> > Lars
> > 
> > Begin forwarded message:
> > > The charter says:
> > > 
> > > "With the output of CONEX, it will be possible to provide 
> sufficient 
> > > information in each IP datagram so that any node in the
> > network can see
> > > the expected rest-of-path congestion."
> > > 
> > > With the scope that I heard on the call which was 
> operation at the 
> > > provider level, and the suggestion from Jari that this
> > might be applied
> > > to PWE3,  the issue of how to make this work in MPLS has to
> > addressed. 
> > > Indeed If the goal is operation at the SP level and PWE3,
> > failure to
> > > find an acceptable MPLS solution would be a showstopper.
> > > 
> > > However if the goal is only to provide a solution that 
> operates at 
> > > parts of the network where the packet  is visible as IP and this
> > is clearly
> > > stated in the requirements then the work has some merit as
> > an experiment.
> > > 
> > > I agree with Adrian that this work looks experimental and
> > really ought
> > > to be an IRTF project, and only when it has been shown to
> > work correctly
> > > in an experimental environment should we do the heavy
> > weight engineering
> > > needed to make this a robust protocol suitable for
> > deployment in the
> > > operational Internet.
> 
> Yes, the intention is for a solution that operates where the packet is
> visible as IP. More precisely, rest-of-path (& whole path) 
> congestion is
> only visible where the packet is IP; congestion info can be set where
> the packet is MPLS using rfc5129.
> 
> > 
> > 
> 
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 13, Issue 45
> **************************************
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 17 Mar 2010 16:26:15 +0000

Ingemar,

>more reasons against this?.

I assume you mean making the outer MPLS shim expose *both* components 
of congestion (upstream and whole path) at every MPLS switch. If so, 
I would put 3 arguments against:
1) as you say, no more room in 3 bits (and probably not anywhere else)
2) MPLS encapsulation doesn't always copy the CoS* field to the new 
outer anyway, when using the pipe model [RFC2983]
3) No need. ConEx info is mostly intended for use at trust boundaries 
between meshed networks, where IP can usually be inspected...

...But if ConEx took off, and some future ConEx w-g wanted to 
standardise ConEx for MPLS interconnect, I'm sure it could be done.

Note: Re-ECN (as an example of ConEx) does not require any changes to 
MPLS switch standards or IP router standards. If congested MPLS 
switches drop packets, re-ECN exposes this congestion - it just 
works. In addition, RFC5129 allows the 3-bit MPLS CoS* field to be 
used both for Diffserv codepoints and ECN marking. And it propagates 
ECN markings from MPLS up to IP on decapsulation.

I know of at least two vendors that have implemented 5129 in MPLS hardware.

* CoS = class of service, which was previously known as EXP (experimental)

>My understanding is that the MPLS limitation is problematic only if 
>one wish to ConEx-police traffic that comes from another ISP and 
>that traffic is MPLS.

Correct.

>It is still possible to do ConEx policing at the label edge routers. 
>Of course the policing point will then not be at the border.

Correct.

Cheers

Bob

> >    1. Re:  CONEX IESG comments #2 ([email-masked])

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design