Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt)

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 01 Aug 2000 11:51:45 +0200

Lou,

>>We have agreed on an "escape code" above (the first "SHOULD") which allows 
>>one to maintain whatever flavor of "standard, non-DS, LSP" he/she liked. I 
>>think this is all the Diff-Serv spec probably needs to say and would 
>>prefer to avoid having to mention in any way QoS support which were 
>>pre-Diff-Ext. So I'd like to leave out the new recommendation.
>>
>>In any case, if a statement about Override option was to be included, I 
>>would argue that it should be a MAY and not a MUST.
>
>I believe I said "SHOULD" not MUST. 

You did say SHOULD, and I did mean that "it should be a MAY and not a SHOULD".

> I'd be fine with a MAY.

Then, can we agree on the principles of this "compromise" position?  i.e.:
	- The text would say that when there is RSVP signaling without the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping".
	- the text would say that an implementation MAY include an option that overrides this.  When this "override option" is set, the LSR then treats LSPs signaled without the DiffServ object as standard, non-DS, LSPs.

If yes, I'll propose exact wording to reflect this.

Thanks

FRancois

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: Lou Berger <[email-masked]>
Date: Tue, 01 Aug 2000 23:53:23 -0400

Francois,

At 11:51 AM 8/1/00 +0200, Francois Le Faucheur wrote:
>         - The text would say that when there is RSVP signaling without 
> the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as 
> a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping".
>         - the text would say that an implementation MAY include an option 
> that overrides this.  When this "override option" is set, the LSR then 
> treats LSPs signaled without the DiffServ object as standard, non-DS, LSPs.
>

Agreed.  Thank you.

I must also apologize.  In all the discussion I dropped one minor, 
hopefully non-contentious point.  When the above option is set, it is still 
desirable to allow the setup of E-LSPs that use default mapping.

To signal this, I suggest using a DiffServ Object with the MAPnb set to 0.

Is this too agreeable?

Thanks,
Lou

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 02 Aug 2000 15:03:10 +0200

Lou,

>To signal this, I suggest using a DiffServ Object with the MAPnb set to 0.

Yes.

Francois

---

From: Lou Berger <[email-masked]>
Date: Wed, 02 Aug 2000 15:37:11 -0400

Excellent.  We're done!

Lou

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 02 Aug 2000 19:33:49 +0200

Lou and everyone,

>Excellent.  We're done!

Here are proposed detailed text changes for review/comment to reflect this
agreement:

          - in section 5.2.1, under MAPnb.
replace "This can be set to any value from 1 to 8" by "This can be set to any
value from 0 to 8." 

          - after the 2nd paragraph of 5.3, add the following new paragraph:
"To establish with RSVP an E-LSP tunnel which uses the Preconfigured EXP<-->PHB
mapping, the sender MAY alternatively create a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object, and  
       - with the DIFFSERV object for an E-LSP containing no MAP entries."

          - after the current 6th paragraph, add the following paragraphs:
"If a DIFFSERV object is not present in the Path message, the LSR SHOULD
interpret this as a request for an E-LSP using the Preconfigured EXP<-->PHB
Mapping. However, for backward compatibility purposes with non-Diff-Serv
Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated
Services Controlled Load or Guaranteed Services, the LSR MAY support a
configurable "override option". When this "override option" is configured, the
LSR interprets a path message without a Diff-Serv object as a request for an
LSP with such non-Diff-Serv Quality of Service. 

If a DIFFSERV object for an E-LSP containing no MAP entry is present in the
Path message, the LSR MUST interpret this as a request for an E-LSP using the
Preconfigured EXP<-->PHB Mapping. In particular, this allows an LSR with the
"override option" configured to support E-LSPs with Preconfigured EXP<-->PHB
Mapping simultaneously with LSPs with non-Diff-Serv Quality of Service.

If a DIFFSERV object for an E-LSP containing at least one MAP entry is present
in the Path message, the LSR MUST interpret this as a request for an E-LSP with
signaled EXP<-->PHB Mapping.

If a DIFFSERV object for an L-LSP is present in the Path message, the LSR MUST
interpret this as a request for an L-LSP."

- in the 11th paragraph of section 5.3:
replace "- the MAPnb field is not within the range 1 to 8" by "- the MAPnb field
is not within the range 0 to 8"

Francois

PS: Below is what section 5.3 would look like with these changes incorporated:

5.3 Handling DIFFSERV Object

To establish an LSP tunnel with RSVP, the sender creates a Path message with a
session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per
[RSVP_MPLS_TE]. 

To establish with RSVP an E-LSP tunnel which uses the Preconfigured EXP<-->PHB
mapping, the sender creates a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object, and 
- without the DIFFSERV object.

To establish with RSVP an E-LSP tunnel which uses the Preconfigured EXP<-->PHB
mapping, the sender MAY alternatively create a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object, and 
- with the DIFFSERV object for an E-LSP containing no MAP entries.

To establish with RSVP an E-LSP tunnel which uses a signaled EXP<-->PHB
mapping, the sender creates a Path message :   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object,  
- with the DIFFSERV object for an E-LSP containing one MAP entry for each EXP
value to be supported on this E-LSP.

To establish with RSVP an L-LSP tunnel, the sender creates a Path message:   
- with a session type of LSP_Tunnel_IPv4, 
- with the LABEL_REQUEST object,  
- with the DIFFSERV object for an L-LSP containing the PHB Scheduling Class
(PSC) supported on this L-LSP.

If a path message contains multiple DIFFSERV objects, only the first one is
meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded.

Each LSR along the path records the DIFFSERV object, when present, in its path
state block.

If a DIFFSERV object is not present in the Path message, the LSR SHOULD
interpret this as a request for an E-LSP using the Preconfigured EXP<-->PHB
Mapping. However, for backward compatibility purposes with other non-Diff-Serv
Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated
Services Controlled Load or Guaranteed Services, the LSR MAY support a
configurable "override option". When this "override option" is configured, the
LSR interprets a path message without a Diff-Serv object as a request for an
LSP with such non-Diff-Serv Quality of Service. 

If a DIFFSERV object for an E-LSP containing no MAP entry is present in the
Path message, the LSR MUST interpret this as a request for an E-LSP using the
Preconfigured EXP<-->PHB Mapping. In particular, this allows an LSR with the
"override option" configured to support E-LSPs with Preconfigured EXP<-->PHB
Mapping simultaneously with LSPs with non-Diff-Serv Quality of Service.

If a DIFFSERV object for an E-LSP containing at least one MAP entry is present
in the Path message, the LSR MUST interpret this as a request for an E-LSP with
signaled EXP<-->PHB Mapping.

If a DIFFSERV object for an L-LSP is present in the Path message, the LSR MUST
interpret this as a request for an L-LSP.

The destination LSR of an E-LSP or L-LSP responds to the Path message
containing the LABEL_REQUEST object by sending a Resv message:   
- with the LABEL object 
- without a DIFFSERV object.

Assuming the label request is accepted and a label is allocated, the Diff-Serv
LSRs (sender, destination, intermediate nodes) must:   
- update the Diff-Serv Context associated with the established LSPs in their
ILM/FTN as specified in previous sections (incoming and outgoing label), 
- install the required Diff-Serv forwarding treatment (scheduling and dropping
behavior) for this NHLFE (outgoing label).

An LSR that recognizes the DIFFSERV object and that receives a path message
which contains the DIFFSERV object but which does not contain a LABEL_REQUEST
object or which does not have a session type of LSP_Tunnel_IPv4, sends a
PathErr towards the sender with the error code ‘Diff-Serv Error’ and an error
value of ‘Unexpected DIFFSERV object’. Those are defined below in section 5.5.

An LSR receiving a Path message with the DIFFSERV object for E-LSP, which
recognizes the DIFFSERV object but does not support the particular PHB encoded
in one, or more, of the MAP entries, sends a PathErr towards the sender with
the error code ‘Diff-Serv Error’ and an error value of ‘Unsupported PHB’. Those
are defined below in section 5.5.

An LSR receiving a Path message with the DIFFSERV object for E-LSP, which
recognizes the DIFFSERV object but determines that the signaled EXP<-->PHB
mapping is invalid, sends a PathErr towards the sender with the error code
‘Diff-Serv Error’ and an error value of ‘Invalid EXP<-->PHB mapping’. Those are
defined below in section 5.5. The EXP<-->PHB mapping signaled in the DIFFSERV
Object for an E-LSP is invalid when:   
- the MAPnb field is not within the range 0 to 8 or 
- a given EXP value appears in more than one MAP entry, or 
- the PHBID encoding is invalid.

An LSR receiving a Path message with the DIFFSERV object for L-LSP, which
recognizes the DIFFSERV object but does not support the particular PSC encoded
in the PSC field, sends a PathErr towards the sender with the error code
‘Diff-Serv Error’ and an error value of ‘Unsupported PSC’. Those are defined
below in section 5.5.

An LSR receiving a Path message with the DIFFSERV object, which recognizes the
DIFFSERV object but that is unable to allocate the required per-LSP Diff-Serv
context sends a PathErr with the error code "Diff-Serv Error" and the error
value "Per-LSP context allocation failure". Those are defined below in section
5.5.

A Diff-Serv LSR MUST handle the situations where the label request can not be
accepted for other reasons than those already discussed in this section, in
accordance with [RSVP_MPLS_TE] (e.g. reservation rejected by admission control,
a label can not be associated).

---

From: Lou Berger <[email-masked]>
Date: Thu, 03 Aug 2000 13:58:02 -0400

Francois,

Looks good, but I have one suggestion listed below.

Thanks,
Lou

At 07:33 PM 8/2/00 +0200, Francois Le Faucheur wrote:
>[...]

I suggest dropping the word "backward".

>[...]

Thanks again,

Lou