The MPLS WG Archive

[<neil.2.harrison@bt.com>]

Hi Deborah,

Think it's high time we distinguished the symptom from the cause here.
The problem is NOT the 1+1 prot-sw scheme...indeed this could be ANY
function.....this is simply a symptom.  So let's first be clear on this
aspect.  The real problem is the way MPLS has been designed.  However,
because of the amount of MPLS deployed to date I believe we will almost
certainly end-up attacking/deprecating things that expose these design
problems....like the 1+1 prot-sw scheme under discussion here.

Despite this we should, IMO at least, attempt to accurately explain WHY
it's creating a problem.....else we are not providing an objective
technical analysis to the larger community.

The real causal problem here is the MPLS stack.  Stacked LSPs do NOT
form a client/server relationship....they are all functionally
coupled....and the functional coupling itself is not consistent.  A key
observation here is that MPLS does not treat its clients
consistently...that is:

-	if IP then => null encaps *OR* peer PDU.....which when coldly
analysed means that a cl-ps IP layer network and (something that looks
like) a co-ps layer network (ie MPLS) are co-existing in the *same layer
network* space.....and for those folks familiar with functional
architecture this should immediately ring alarm bells as 'a bit of a
problem'.....this BTW is one of the reasons why some folks are pushing
T-MPLS...however I don't want to get into that particular symptom here.

-	if MPLS then => digital wrapper.....this holds the tantalising
illusion that one can create topology on the fly by simply adding
another MPLS header.....this, however, does not work.

-	if 'other' then => PW encapsulation.  This is a direct
consequence of the above.  Its practical impact however was fairly
benign when PWs were restricted to 1-hop as we could treat these largely
as a form of 'adaptation'.  However, when PW entities become multi-hop
we have no choice but to start off down the road of creating a new co-ps
mode PW layer network above the hybrid IP/MPLS layer network.  That is
just the way it is.


Now let's return to the 1+1 prot-sw symptom and try and understand why
it exposes a design problem for MPLS against the above background.

-	the MPLS digital wrapper stack uses the rules:  (i) if S=0 then
another MPLS header follows and (ii) if S=1 another MPLS header does not
follow.....so what does follow?

-	well, it might be an IP packet or it might be a PW encapsulated
packet.  Noting that because of the different way MPLS treats its
clients (including itself as a digital wrapper) AND the fact that ECMP
mechanisms use the 1st nibble of an IP packet to distinguish v4 and v6
variants, the PW encapsulated packet must have a way to distinguish
itself from the IP packet in the 1st nibble.  Ergo the control-word
structure of PW adaptation....at least the 1st nibble therein.  Same
distinguishing issue arises with the VCCV stuff....which is now yet
another client type but only applicable with PWs (ie PW and VCCV clients
are muxed together).

-	a critical question we should ask at this point is 'what happens
if MPLS LSPs get misconnected?'  And the first architectural design
observation we can make here is that the functional fields in traffic
units SHOULD (though I would say MUST) have consistent semantics if,
under misconnectivity, the consequential behaviour is to be
consistent/predictable....this should be especially obvious as a
requirement for the OAM mechanisms if nothing else!

-	so let's look at MPLS itself here.  The S/EXP/TTL fields do
remain fairly consistent but the label field does not.  The 1st
functional split relates to the 0-15 reserved labels (that imply an
'action') and the rest of the labels.....nothing wrong here in concept
as the semantics are clear and not assigned to arbitrary labels.  Now in
normal co-ps mode destination forwarding the label is a
locally-significant (ie link connection) proxy for the trail's
globally-significant destination address (DA).  However, in MPLS we also
permit mp2p merging behaviour (both LDP and PHP create merging).  This
requires that labels must also be able to take on a different functional
'demerging' role of being a proxy for a trail's globally-significant
source address (SA).  Further, there are 2 subtle spins on this:
	* if the client is a PW then the demerging label provides a 1:1
identification of the ultimate client instance;
	* if the client is a rfc4364 (ex rfc2547) IP VPN then the
demerging label only resolves to a specific client VRF instance within a
certain VPN.....the ultimate (IP) client is then always resolvable
within its VPN instance because cl-ps mode traffic units MUST always
carry globally-significant (ie with the layer network of interest...here
a VPN) SA label.

-	so we already see we do not have consistent label semantics in
MPLS per se.  And because LSPs can be stacked and are functionally
coupled, then not only can we have misconnectivity between LSPs at the
same level in the stack but also between LSPs at different levels in the
stack.  So under misconnectivity the way in which the receiving LSR
regards the semantics of the label field may not be consistent.

-	now let's now look at the 1+1 prot-sw function mentioned in
Y.1720 in the context of the above;
  
-	if the 1+1 function is below (ie payload to) an MPLS header with
S=1 (ie no more MPLS headers follow) then there is no problem if there
is no misconnectivity.  However, under misconnectivity to a non 1+1
receiving LSR, that LSR will attempt to parse the payload as either an
IP packet or a PW packet.....and the consequential behaviour will not be
consistent/predictable because it will depend what is in the 1st nibble
of the payload as the receiving LSR interprets this.  Note however that
if we ran, for example, a Y.1711 OAM CV flow on this LSP (actually ALL
LSPs because we do not know which LSPs will experience misconnectivity
ahead of the event) we should be able to detect the problem.  Note also
the importance of running the SAME OAM mechanism on all LSPs.....it is
NOT sufficient to have OAM only associated with PWs!

-	if the 1+1 function can exist immediately following an MPLS
header with S=0 then this is IMO a direct violation of the MPLS stacking
rules *irrespective* of the effects of misconnectivity.  Why?  Because
normally this (ie S=0) indicates that this is not the bottom of the MPLS
header stack and that a further MPLS header follows.....but here it is
not an MPLS header that follows but (in this case) a 1+1 prot-sw
function.

-	now consider what happens under misconnectivity in the S=0 case.
This is NOT like the previous S=1 case because the receiving LSR will
attempt to parse the next 4 octets as an MPLS client header (and not an
IP or PW client as in the S=1 case).  However, it seems this case would
also be detectable if one ran a Y.1711 OAM CV flow (and on ALL LSPs for
the reasons noted previously).  Note again the importance of running the
SAME OAM mechanism on all LSPs.....it is NOT sufficient to have OAM only
associated with PWs!


So what do we conclude/learn from all this.

1	Well, the real problem lies with MPLS and not the 1+1 scheme per
se.
2	But it's far too late now to go back and re-spin MPLS (maybe the
T-MPLS advocates disagree?)
3	If we ran a consistent OAM CV flow that contains a true SA on
ALL LSPs (and not just PWs) (eg as described in Y.1711 say) we should be
OK.....however, nothing works well in the context mp2p merging
constructs, and its not just the OAM efficacy that is impacted but it
also forces us to use varying labels semantics as I discussed above that
also creates a problem itself under misconnectivity....just a fact.
4	Perhaps the easiest solution is to attack/deprecate the Y.1720
symptom and ban it from MPLS?.....all the above stuff does not 'go away'
of course but it may be the simplest expedient course of action.

Sorry for the length of this mail....but I  think it important to try
and properly explain what is going on here (at least as I see/understand
it).

regards, Neil

 
> -----Original Message-----
> From: BRUNGARD, DEBORAH A, SBCLABS [mailto:dbrungard@att.com] 
> Sent: 26 January 2007 20:03
> To: Huub van Helvoort
> Cc: mpls@ietf.org; pwe3@ietf.org
> Subject: [mpls] RE: [PWE3] Re: Y.1720 liased text
> 
> 
> FYI-
> This 1+1 packet protection scheme was not only in ITU's SG13 
> work, it was also included in SG15's G.7712, done at the same 
> time (2003). G.7712 doesn't reference Y.1720, probably as 
> they were being done at the same time, though the scheme was 
> of the same origin.
> 
> G.7712's Appendix IV does say that the implementation is 
> "non-trivial", maybe there have been no attempts.
> 
> (ITU Recommendations (PDF) can be downloaded for free)
> 
> Deborah   
> 
> -----Original Message-----
> From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
> Sent: Friday, January 26, 2007 2:03 PM
> To: Adrian Farrel
> Cc: mpls@ietf.org; ghani.abbas@ericsson.com; pwe3@ietf.org; 
> Stewart Bryant
> Subject: Re: [PWE3] Re: Y.1720 liased text
> 
> Hi Adrian,
> 
> You wrote:
> 
> > Hi Huub,
> > 
> >>> The implication of the text is that you can have a packet of the
> >>> form:
> >>>
> >>> LSE (RFC3032)
> >>> Sequence number
> >>> LSE (RFC3032)
> >>> Payload
> >>>
> >>> Is that correct?
> >>
> >> This is also what I read, and apparently Neil does as well.
> >>
> >>> If so what is the setting of the S bit (See RFC3032) in each case?
> >>
> >> Because the text does not mention any altering of the 
> S-bit I assume 
> >> they do not change.
> > 
> > Ah, so either setting of the S-bit is allowed?
> 
> [hvh] the text does also not mention a specific value of the S-bit,
>        so I suppose either value of the S-bit is allowed.
>        If I would try to implement this protection, the LSR
>        providing the protection would build the LSE according to
>        RFC3032 and then add the 4 octet sequence number.
> 
> >> I agree with Neil (see his 2002 post) that this requires a very 
> >> carefull configuartion of the network. Checking that both ends 
> >> support this feature and closely guard the connectivity for both 
> >> diverse routes.
> > 
> > With the S-bit, careful config is needed.
> 
> [hvh] indeed I did mean careful
> 
> > Without the S-bit it seems like a router that popped a label would
> > expect the next thing on the stack to also be a label, but would 
> > actually find a magic sequence number.
> 
> [hvh] if the the config was careful the router that pops the 
> label inserted by the router that is the source of the 
> protection knows that the 4 octets following this popped 
> label is the sequene number and treats it accordingly.
> 
> > Although you could config around
> > this (since the pop action must be installed) this is a new MPLS 
> > behavior. At the least it is a new LFIB action that is not 
> previously 
> > described in any MPLS documentation.
> 
> [hvh] ehh, it was described in 
> http://www.watersprings.org/pub/id/draft-nagarajan-ccamp-mpls-
> packet-pro
> tection-00.txt
>        This draft was presented and discussed in the IETF53 meeting.
>        The meeting notes nor the discussion afterwards on the 
> MPLS WG list
>        mention the fact that it contains a new LFIB action.
> 
> >> Note that this text is in an appendix, so it does not form an 
> >> integral part of the recommendation, i.e. it is not mandatory.
> > 
> > Hmmm.
> > 
> > Shouldn't there be a specification of:
> > - what must be supported
> > - what can also be attempted
> 
> [hvh] maybe, but apparently when the text was drafted there were no
>        contributions providing/requesting these specifications, and
>        when the recommendation was approved (as usual in ITU-T by
>        consensus) nobody objected, in the meeting of the Q3/13, at
>        the closing plenary, nor during the AAP.
> 
> > I think Stewart's question is quite helpful here. Do we 
> have any idea
> of 
> > what deployed implementations do?
> 
> [hvh] That would be a question to ask on the ITU-T Q9/15 exploder
> 
> > Cheers,
> > Adrian
> 
> Cheers, Huub.
> 
> -- 
> ================================================================
>                    http://www.van-helvoort.eu/ 
> ================================================================
> Always remember that you are unique...just like everyone else...
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls