Re: [re-ECN] ConEx and MPLS (Was Re: CONEX IESG comments #1 ([e-mail]))

[Bob Briscoe <[e-mail]>]

Ingemar,

At 12:15 16/03/2010, Ingemar Johansson S wrote:
>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?.

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


>Regards
>Ingemar
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of [e-mail]
> > Sent: den 16 mars 2010 11:24
> > To: [e-mail]
> > 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
> >       [e-mail]
> >
> > 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
> >       [e-mail]
> >
> > You can reach the person managing the list at
> >       [e-mail]
> >
> > 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 ([e-mail])
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 16 Mar 2010 10:24:04 -0000
> > From: <[e-mail]>
> > Subject: Re: [re-ECN] CONEX IESG comments #2
> > To: <[e-mail]>om>,  <[e-mail]>
> > Message-ID:
> >
> > <[e-mail]1
> > .systemhost.net>
> >
> > Content-Type: text/plain;     charset="us-ascii"
> >
> > In-line
> > Best wishes
> > phil
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Lars Eggert
> > > Sent: 01 March 2010 15:34
> > > To: [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/re-ecn
> >
> >
> > End of re-ECN Digest, Vol 13, Issue 45
> > **************************************
> >
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design