[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt


Bob,

thanks for useful comments :)

Bob Briscoe wrote:

Loa,
I believe this draft has no technical effect. However there is some truth in the idea that names are important. 

So, let's set aside a few clock cycles to consider this...
1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP field for ECN in MPLS), is it really appropriate now to call this a CoS field? 

Thinking out loud...
- CoS is a signal from an ingress to the interior (a request for a certain class of service), - whereas ECN is a signal from the interior forwarding plane to the egress (a response from the interior saying whether the class of service requested was congested).
The way 5129 was done, two (or more) EXP codepoints can be designated as the same CoS, but one can be used to say "this packet experienced congestion when using this CoS", while the other says "it didn't". So, I guess I could live with this field being called CoS, even though it's not strictly correct. I can't think of anything better. 

We had the same discussion when we started to discuss this draft, we
wanted to find a name the covered both cases. We just couldn't come
with a better name, so we said "Let us call it 'CoS Field'" and change
it someone comes up with something better.

I'm still open to do that change, but time is kind of running out, the
latest point in time we can do this change is an RFC editor note, when
the IESG has approved the document.
2/ BTW, Thanks for pointing out that the RFC Index doesn't identify RFC5129 or RFC3270 as updates to RFC3032.
According to a recent discussion on TSVWG with Bob Braden, the annotation of the RFC Index is the responsibility of the RFC Editor, and doesn't need to be driven by text in RFCs. So we can send an email to the RFC Editor at any time asking for annotation to be added to the index. 

If no-one objects on this thread, will you be doing that? If not, I can.


I'll do it.
But does 5129 UPDATE 3270? I don't believe it does. 5129 deliberately doesn't change or contradict anything in 3270. It complements it. 

I tend to agree, but have a problem how to capture this. We have

obsoletes
obsoleted by
updates
updated by

Would the following change to the paragraph in the ID suffice:

                                   "We recommend this scheme, which we
      call `per-domain ECT checking', and define it more precisely in
      the following section.  Its chief drawback is that it can cause
      packets to be forwarded after encountering congestion only to be
      dropped at the egress of the MPLS domain.  The rationale for this
      decision is given in Section 8.1.  This scheme is an update to RFC
      3032 [RFC3032] and RFC 3270 [RFC3270] is extended to allow for
      CoS Field code points to encode ECN information."

and - yes if you agree and could improve on grammar that would be great.

"The problem" I have is that even with the changed version this is an
"updates/updated by" the way it is used by the RFC Editor. We want to
point to this extension from 3270 to give implementation context.


/Loa

PS
you helped me pick another nit alos 5219 should be 5129




Thoughts?


Bob

At 12:59 10/07/2008, Loa Andersson wrote:

All,

this mail initiates a two week multiple-working group last call on

draft-ietf-mpls-cosfield-def-04.txt

Background:

The name "EXP field" of a three bit field in the MPLS shim header,
and the statement in RFC3032 "For experimental use" has led other
SDOs to believe that this field could be used for any type of
experiments. The field has however from the start been intended to
carry Class of Service (CoS) information.

The draft therefore renames the field "Class of Service (CoS) Field".

This is an update of RFC3032, and also of drafts that builds on
RFC3032. This multiple-working group last call is therefore sent to
working groups with RFCs that has been updated.

The document has been through wg last call in the mpls working group,
which I don't think will stop that wg producing new comments now,
nor should it :) .

This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG.

Since this is also of interest in the work we started on a
Transport Profile for MPLS (MPLS-TP) we are also sending it to the
Ad HoC Team on MPLS in the ITU-T.

Please review and send comments to the mpls wg mailing list, or to
the mailing list for mpls-tp discussion that just been set up:

mpls-tp@ietf.org

or directly to the mpls wg co-chairs before e.o.b. July 24.

/Loa

--
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                           loa@pi.nu
____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 




--
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                           loa@pi.nu