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

[Loa Andersson <[e-mail]>]

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:
>>
>> [e-mail]
>>
>> or directly to the mpls wg co-chairs before e.o.b. July 24.
>>
>> /Loa
>>
>> -- 
>> Loa Andersson
>>
>> Principal Networking Architect
>> Acreo AB                           phone:  [phone]
>> Isafjordsgatan 22                  mobile: [phone]
>> Kista, Sweden                      email:  [e-mail]
>>                                            [e-mail]
> 
> ____________________________________________________________________________ 
> 
> 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:  [phone]
Isafjordsgatan 22                  mobile: [phone]
Kista, Sweden                      email:  [e-mail]
                                            [e-mail]