Subject: Simplifying tunnel modes Re: Last Call feedback on MPLS-Diff-Serv

From: Grenville Armitage <[email-masked]>
Date: Sun, 02 Jul 2000 13:04:38 -0700

Hi Francois,

Replying to another part of our discussion (simplifying
the tunnel mode specifications in 2.6.3 and 2.6.4):

Francois Le Faucheur wrote:

	[..]
> >#5 Vastly simplify sections 2.6.3 and 2.6.4 (tunnel models)
> >
> >   The last paragraph of 2.6.4 admits that basically the only
> >   difference between the Uniform and Pipe models is in the
> >   push/pop behaviors. At the very least 2.6.4 can be vastly
> >   simplified by simply specifying the 'Pipe Model' in terms
> >   of how it differs from the 'Uniform Model' in 2.6.3 (right
> >   now 2.6.4 contains a load of redundant descriptive text).
> >
> 
> Yes, as pointed out in the draft, the two models "only" differ in
> their push and pop behaviours. But the push and pop  behaviours
> (with/without PHP) are the complex aspects discussed in a big part
> of the text anyway (the swap behavior is quite straight-forward
> in both models). So , saying they "only" differ by push/pop doesn't
> mean that you would save that much text by describing operations
> of Pipe as delta over Uniform.

My gut feel is that descriptions of the push/pop behaviors could
be made much more concise - I wont argue that they're the key
differences between the two models. But without sitting down to
rewrite both sections, I'll settle for the edits you propose
below :)
 
> However, we could simplify 2.6.3 by combining the 2nd paragraph
> ("With this Uniform Model:...") with the last paragraph ("For
> support of the Uniform Model over an LSP ...").

Yes, that would be a great improvement. The last paragraph (and
its bullet points) in 2.6.3 practically represents the necessary
and sufficient text to describe Uniform mode of operation. The
redundancy between the 2nd para (and bullets) and the last para
(and bullets) was one of things that worried me about this section.

I would also take a further step and remove descriptive text
regarding LSR hops that only perform label swapping. Since we
are, by definition, talking about MPLS I think readers can be
assumed to understand that in the middle of an LSP LSRs only
operate on the outermost header.

(Also, the 2nd last bullet in the 2nd para "-It is also possible
to not use PHP..." seems rather convoluted in that it covers
non-PHP as a special case, whereas we all know that non-PHP is
simply where the penultimate LSR is just a regular old LSR doing
regular old label swapping. In the non-PHP case indeed there is
nothing special about a penultimate LSR anyway. Hopefully this
description will disappear when you collapse the 2nd and last
paras in 2.6.3)

> Similarly we could simplify 2.6.4 by combining the 3rd paragraph
> ("With this Pipe Model: ...") with the two paragraphs before last
> ("For support of the Pipe Model over an LSP...").

Yes, that would similarly be a great improvement (applying again my
comments about removing special text discussing LSRs that only
'swap' since that's just regular MPLS, and deconvolute discussions
about non-PHP penultimate behavior since that's just regular swapping
too.)

(Finally, I wonder how normative this tunnel text ought to be anyway,
given that its architectural genesis lies in the DiffServ WGs
tunnel document currently heading for Informational status? Aren't
we preempting the evolution of DiffServ-style tunneling architectures?)

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 03 Jul 2000 16:55:17 +0200

Grenville,

>the tunnel mode specifications in 2.6.3 and 2.6.4):

<clip>

>Yes, that would be a great improvement. The last paragraph (and

Will do. I may get you to check the new text off-line.

>operate on the outermost header.

I'd like to keep the statement about intermediate LSRs. It is one sentence long and simple. You may argue that it is stating the obvious but I think it should be clearly stated once. 

>non-PHP as a special case, 

agreed.

>whereas we all know that non-PHP is

agreed.

>about non-PHP penultimate behavior since that's just regular swapping

ditto.

<clip>

thank you

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: Grenville Armitage <[email-masked]>
Date: Mon, 03 Jul 2000 10:27:25 -0700

Francois,

One quibble:

	[..]
> I'd like to keep the statement about intermediate LSRs. It is
> one sentence long and simple. You may argue that it is stating
> the obvious but I think it should be clearly stated once.

I certainly think it is reasonable to remind readers that a transit
LSR just forwards using the top label. But my feeling is that this
concept is raised already in a number of ways around the document:

 - Last sentence, first para, section 1
 - Last sentence, first para, section 1.2
 - 2nd sentence, 1st para, section 1.3
 - All of section 2.1, arguably all of 2.4
(And specifically in section 2.6)
 - Section 2.6.1, sub-bullet 2 (the quote from MPLS_ARCH)
 - Section 2.6.3, 1st para, 3rd&4th sentences beginning "In this model"
 - Section 2.6.3, 2nd bullet under "With this Uniform Model:"
 - Section 2.6.4, 2nd bullet under "With this Pipe Model:"
....

I would suggest it would be sufficient to remind readers that
"LSRs in the middle of an LSP perform forwarding, queuing, and
scheduling based solely on the outer MPLS Header consisting of
Label and EXP field." This clarification could be placed at the
start of section 2 as a whole, and thereby allow removal of similar
subsequent texts. IMHO :)

cheers,
gja

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 03 Jul 2000 17:25:26 -0700

Hi Francois,

Following up on this subtopic (rationalizing sections 3 and 4)
I only have some suggestions and observations rather than
strong requests. Mostly I'm working with a gut feel that there's
a way to combine many of the similar elements in the definitions
of both E- and L-LSPs. Hopefully the following might be helpful :-)

> >#8 Rationalize sections 3 and 4
	[..]
> >  (Indeed, these two sections could probably be
> >   beneficially collapsed into one section.)
> 
> I am not sure what you are calling the "two sections" (ie 3 and 4 ,
> or 3.5 and 4.5)

I was thinking of 3 and 4 as a whole.

> Although the descriptions of E-LSPs and L-LSPs have a number of things
> in common, they have a lot of differences:
>         - 3.2 and 4.2 are completely differnet. 3.2 uses
>           preconfigured/signaled mappings applying on EXP
>           only, 4.2 uses MAndatory/Default mappings applying
>           to EXP/CLP/DE.

It occured me that section 3.2 is really a subset of 4.2 that differs
primarily in the scope of default mappings. I would write a combined
version of these sections as:

 "Populating Encaps-->PHB mapping"
	- For an E-LSP this table only contains mappings of the
	  form  EXP->PHB. In the absence of any other mappings
	  configured or signalled by the network operator for the
	  E-LSP, the default mapping maps all EXP values to the
	  BE PHB.
	- For an L-LSP this table may have one or more
	  entries, and in each case the entries indicate only
	  the drop precedence to be applied within the context of
	  the PSC associated with the L-LSP.
		- [Go on to list the current default mandatory EXP->PHB,
		   CLP->PHB, and DE->PHB mappings]

Also, in light of sections 7, 8, 9, and 10 specifying the circumstances
underwhich each of the various types of Encaps<->PHB mappings are utilized,
we could remove the equivalent descriptive texts from 4.2.1, 4.2.2,
and 4.2.3 (e.g. section 4.2.3's "If the LSR does not terminate an MPLS
Shim Layer over this incoming label..." description is superceded by
text in section 9, and therefore isn't needed in 4.2.3) Focus on what
the mapping rules *are* in 4.2, and leave it until section 7, 8, 9,
or 10 to specify *when* each of these mappings would be used.

>         - 3.4 and 4.4 are very differnet. 3.4 must have a PHB-->EXP
>	    mapping  while 4.4 may or may not have a PHB-->EXP mapping.

Okay. So both sections could be replaced by a single section discussing
PHB->EXP mappings, and a qualifying statement that an E-LSP requires
such a mapping while an L-LSP MAY have such a mapping ?

>	    3.4 uses configured signaled mapping to populate it. 4.4 uses
>	    Mandatory mapping.

If I was writing this as a single section, a single line of text would
suffice to note whether mappings could be configured, signaled, or used
mandatory mappings. 

>	    4.4 needs to cover the cases  of LC-ATM
>	    and LC-FR while 3.4 shoudl not. 4.4.4 is the same as 3.4.4
>	    and already use a refernec to 3.4.4.1.

I dont follow see that this is a major distinction. For example,
sections 3.4.2 and 4.4.2 are practically identical bar some minor
special case observations for 4.4.2 - especially clear since much
of the wordage in 4.4.2 defaults to "Use the mappings in 3.4.2.1".
So instead, why not just use the text in 3.4.2, the default mappings
in 3.4.2.1, and the special-case text in the final para of 4.4.2
to clarify some differences between E- and L-LSP scenarios when
mapping PHB->CLP ?

I notice equivalent similarities between other sections 3.4.*
and 4.4.*, which is why it seems to me there's a lot of redundant
text. (For example, I struggle to find meaningful differences
between 3.4.4 and 4.4.4 that would prevent them being merged,
or one being a reference to the other.)

> So section 3 and section 4 could not be collapsed together.
> 
> 3.3 is indeeed a subset of 4.3, but 3.3 already boils down to
> a single paragraph so I am not sure we would gain much by replacing
> that with a cross-reference. Also you might have to clarify that
> only a subset of the cases are relevant to E-LSPs to avoid confusion.
> So there is not much to be gained there.

At least it does show we could replace these two sections by
a single one (if one was inclined to collapse 3 and 4 together,
which I'm hoping to convince you is feasible and would greatly
benefit your document :-)

(Actually, I'd even go so far as to suggest that 4.3.1, 4.3.2,
and 4.3.3 are superfluous - since all they essentially state
is "If the 'Encaps-->PHB mapping' is of the form 'XXX-->PHB'
then determine the PHB by looking at the XXX field". This
hardly seems to make 4.3 and 3.3 all that different, since
3.3 is the same process applied solely to the EXP-->PHB case,
i.e. equivalent to 4.3 & 4.3.1)

> 3.5 and 4.5 are the only ones that could usefully be combined.
> With very minor editing around, 4.5 could be replaced by a
> reference to 3.5.

I think that would be beneficial, yes.

I would also suggest that 3.6 and 4.6 (on merging) could easily
be written as a single section too, since the principles of
merging are common. It is only the specific restrictions on
when merging can/cannot occur that differ - and in each section
you've already captured those restrictions in a single sentence
anyway.

> 
> >   A lot of the wording in both sections ought to be tightened
> >   up significantly to focus primarily on the normative
> >   statements.
> >
> 
> Could you provide specific suggestions? or at least point us towards
> the issues you see?

Hopefully the above helps somewhat :)

cheers,
gja

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 03 Jul 2000 18:05:43 -0700

Francois,

Wrapping up the last open issue, I promise ;)

> At 01:26 26/06/2000 -0700, Grenville Armitage wrote:
	[..]
> >#10 Why is section 7 here?
> >
> >  Section 7 repeats material that is redundant for a reader who
> >  gets this far into the document. Clearly the mechanisms for
> >  handling MPLS over PPP are documented elsewhere, and this
> >  document has already stated how various Encaps<->PHB mappings
> >  are built for E- and L-LSPs. Section 7 ought to be removed,
> >  perhaps to an informational/applicability document.
> 
> Section 7 is NOT redundant. It specifies , out of all the previously
> defined options, which ones are MUST and which ones are MAY for PPP
> interfaces. Unless you specify that you may have one implemnetation
> supporting one option and another implementation supporting another
> option which prevents actual interoperability.

Oh, I certainly agree such information is worthwhile.  The MUST/MAY
text in section 7 just seemed overly wordy (and that probably made
me feel a lot of it wasn't neeeded). It simply boils down to
saying that "E-LSPs with configured EXP<-->PHB mappings MUST
be supported, signalled mappings MAY be supported, and L-LSPs
with signalled mappings MAY be supported". There, done in one
sentence :-)  (There are couple of instances of "..then it MUST do
so in compliance with all the material from this specification
pertaining to.." which is just distracting fluff - the normative
text is normative, no need to add eyestrain to the readers by
restating that they're reading a normative spec ;)

(7.2 and 7.3 could also be collapsed into 7.1 by removing the
words "..specified in section 7.1.." from each and removing
the subsection headings.)

> >#11 Why are sections 8 and 9 here?
> >
> >  Sections 8&9 suffer the same question of focus as section 7.
> >  How an ATM or FR interface operates is pretty much covered by
> >  existing MPLS documents - excluding perhaps the recommendation
> >  to use EPD for ATM, I dont see sections 8&9 adding anything
> >  normative to what has already been stated earlier in the document.
> >  They ought to follow section 7 into another document (or oblivion).
> >
> 
> Same as above, these sections clarify which of the various options
> are applicable to these media.
> Also it clarifies media specific issues which have come up during
> the WG progress (eg that the requirement is for ATM LSRs to support PHB
> scheduling rather than "traditional" ATM scheduling, that only two drop
> levels are supported , that EPD is a good idea, that the spec only
> covers the case where the shim layer is used...)
> 
> I believe this is useful information and should be kept.

Okay. I would suggest removing a few instances of redundant
"..in compliance with all the material from this specification
pertaining to.." wordage.

However, 2nd para in 8.2 "Since there is only one bit..." seems
unecessary in light of all the previous discussion about how
to map PHB->CLP for L-LSPs (and oddly it points back to DIFF_AF
as the normative behavior reference, instead of the PHB->CLP
mapping rules already stated in this document). Ditto for
2nd para in 9.2 - I'd have thought a backwards reference to this
document's own PHB->DE mapping rules would be less confusing to
readers.

> >#12 Why is section 10 here?
> >
> >   Again, as with section 7 there's an issue of focus here.
> >   No new normative text exists here, and it is at best a subset
> >   of section 7 anyway.
> >
> 
> Section 10 is NOT redundant. It specifies , out of all the previously
> defined options, which ones are MUST and which ones are MAY for LAN
> interfaces. Unless you specify that, you may have one implemnetation
> supporting one option and another implementation supporting another
> option which prevents actual interoperability.
> 
> We could easily group it with section 7 though.

Folding LSR over LAN interfaces into section 7 would be good.

cheers,
gja

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 04 Jul 2000 11:34:23 +0200

Grenville,

>Wrapping up the last open issue, I promise ;)

getting there '^)

>Oh, I certainly agree such information is worthwhile.  

Good. 

>The MUST/MAY

Will do.

>the subsection headings.)

I'd prefer to keep the 7.2 and 7.3 section titles. It will be useful for people to see where those particular cases are discussed (e.g. from the Table of Content that we will add in next Rev).

>pertaining to.." wordage.

will do.

>as the normative behavior reference, instead of the PHB->CLP

Section 8.2 focusing on implementation of "Diff-Serv PHBs" in an ATM context. 
The mapping into CLP has been detailed earlier and we don't need to get back to it here. The point we wanted to bring forward is that although the AF Spec defines 3 levels of drops , it does discuss the case where only two levels of drop are supported and this is the case that applies to ATM Diff-SErv LSRs.

>Folding LSR over LAN interfaces into section 7 would be good.

will do.

thnaks

Francois

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 04 Jul 2000 10:09:18 -0700

[..]
> The mapping into CLP has been detailed earlier and we don't need
> to get back to it here. The point we wanted to bring forward is
> that although the AF Spec defines 3 levels of drops , it does
> discuss the case where only two levels of drop are supported
> and this is the case that applies to ATM Diff-SErv LSRs.

But that's my point - the fact that there are only 2 drop values
in ATM, and the implications for AFxy mapping, has already been
documented earlier in *this* spec when the PHB<-->CLP mappings
are defined. 4.2.2 and 4.4.2 are clear about the mapping rules
to 3 AF drop precedence. If section 8.2 simply pointed back to
the earlier discussion of AFxy<-->CLP mappings the text would be
more self contained (and readers would be less likely to wonder
if 8.2 is actually providing some further insight or normative
requirement over and above 4.2.2 and 4.4.2, which it does not).

That's a minor confusion easily avoided, either by removing 8.2
or at least writing the text like "Only two possible drop precedence
may be indicated by the CLP bit. Sections 4.2.2 and 4.4.2 define
how three AFxy precedence levels [DIFF_AF] are mapped to these
two values."

cheers,
gja

---

From: Grenville Armitage <[email-masked]>
Date: Tue, 04 Jul 2000 10:27:14 -0700

clarification to my post a few minutes ago - meant
to focus on the 2nd para of section 8.2:

Grenville Armitage wrote:
	[..]
> If section 8.2 simply pointed back to
    ^ "2nd para of.."
> if 8.2 is actually providing some further insight or normative
    ^ "2nd para of.."
> That's a minor confusion easily avoided, either by removing 8.2
                                             "2nd para of.." ^

cheers,
gja