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

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

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

Date: Mon, 12 Apr 1999 09:50:13 -0400
From: "Black, David" <[email-masked]>
Subject: RE: ECN: Tunnel/SA relationship
To: "'Brian E Carpenter'" <[email-masked]>, "Erik Nordmark"
<[email-masked]> Cc: "Black, David" <[email-masked]>,
"'Jun-ichiro itojun Hagino'" <[email-masked]>, [email-masked],
[email-masked], "[email-masked]'" <[email-masked]>

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----------------<