Subject: (ngtrans) diff-serv comment 5 on transition mechanisms

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 Apr 1999 13:39:43 -0700 (PDT)

>----------------Begin Forwarded Message----------------<

Date: Mon, 12 Apr 1999 17:27:01 +0100
From: "Brian E Carpenter" <[email-masked]>
Subject: Re: ECN: Tunnel/SA relationship
To: "Black, David" <[email-masked]>
Cc: "Erik Nordmark" <[email-masked]>, "'Jun-ichiro itojun Hagino'"
<[email-masked]>, [email-masked], [email-masked],
"[email-masked]'" <[email-masked]>

It may be cryptic, but I wouldn't want to force another Last Call
upon Erik's document, so I aimed at a change that can 
considered editorial.

  Brian

Black, David wrote:
> 
> Brian,
> 
> That's somewhat cryptic, and doesn't provide much guidance
> to an implementer who hasn't been following diff-serv.
> 
> How about something along the lines of:
> 
> Encapsulation: MUST/SHOULD copy out IPv6 DSCP to
> IPv4 DSCP.  SHOULD set IPv4 DSCP to 0 if resulting
> value would otherwise cause problems (e.g.,
> implied IP Precedence of 6 or 7 for non-routing traffic).
> 
> Decapsulation: MUST/SHOULD copy in IPv4 DSCP to IPv6
> DSCP, unless IPv4 DSCP is 0, in which case do
> nothing (both for backwards compatibility and to deal
> with the "set to 0" case in Encapsulation).
> 
> Not sure what to do about the other two bits - I'm
> inclined to say nothing to avoid the dependency problem
> you pointed out, BUT can we point to the ECN RFC
> as something the implementer might want to be cognizant
> of without making a normative reference to it (i.e., as
> a hint)?
> 
> Also, what mailing list does this need to go on when
> we reach rough consensus here (diff-serv) on what to do,
> ngtrans?
> 
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
> [email-masked]
> ---------------------------------------------------
> 
> > -----Original Message-----
> > From: Brian E Carpenter [SMTP:[email-masked]]
> > Sent: Monday, April 12, 1999 4:30 AM
> > To:   Erik Nordmark
> > Cc:   Black, David; 'Jun-ichiro itojun Hagino'; [email-masked];
> > [email-masked]; [email-masked]'
> > Subject:      Re: ECN: Tunnel/SA relationship
> >
> > Aargh. Good catch. We have a problem.
> >
> > The encapsulation/decapsulation text is wrong. It says the
> > encapsulating IPv4 header has TOS=0 and that it is simply
> > is discarded upon decapsulation.
> >
> > Suggestion:
> >
> > > 3.5.  IPv4 Header Construction
> > ..
> > >         Type of Service:
> > >
> > >                0
> >
> > becomes
> >                 0 unless otherwise required by Differentiated
> >                 Services [RFC 2474, RFC 2475].
> >
> > > 3.6.  Decapsulation
> > ...
> > > The encapsulating IPv4 header is discarded.
> >
> > becomes
> >  The encapsulating IPv4 header is discarded unless otherwise
> >  required by Differentiated Services [RFC 2474, RFC 2475].
> >
> > I can't suggest anything for ECN since it isn't standards track
> > and you would have an ugly dependency problem.
> >
> >    Brian
> >
> > Erik Nordmark wrote:
> > >
> > > The update to RFC 1933 (draft-ietf-ngtrans-mech-02.txt) is currently
> > > in IETF last call. So if there is a strong reason for changing the
> > behavior
> > > for the DSCP or ECN bits now is the time to make your voices heard!
> > >
> > >   Erik

>----------------End Forwarded Message----------------<