Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 1 Aug 2010 11:08:17 +0300

Maarten,
The "broadcast bridge" you mention is IMO something foreign to MPLS (and, by implication, MPLS-TP) data plane.
(One more point where MPLS is very much different from Ethernet.)
E.g., note that labels on the copies of "broadcasted" packets have to be, generally speaking, different.

I will check the linear protection draft; if it refers to this construct, I'd say it has serious problems.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Friday, July 30, 2010 11:13 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Sasha,

In Ethernet and MPLS-TP type packet transport networks we use 1:1 SNC/S
protection with a "broadcast bridge". Note that a "broadcast bridge" is not
the same as a "permanent bridge" used in 1+1 SNC protection.

A "broadcast bridge" sends under non-SF/SD conditions traffic to the working
connection only. Only during SF or SD conditions the traffic is send to both
the working and the protection connections. This implies that traffic is
send to both working and protection connections for a few hours per year
only (assuming a typical MTTR of about 4 hours).

A "permanent bridge" send traffic under all conditions to both working and
protection connections. In packet transport networks (Ethernet, MPLS-TP)
such "permanent bridge" would be used only for 1+1 unidirectional p2mp SNC/N
protected LSPs or PWs. The unidirectional nature of the p2mp connections
require for the case of protection that both working and protection
connections carry the traffic so that the tail end (i.e. leaf nodes) can
perform the protection switching locally.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: donderdag 29 juli 2010 12:27
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten, Curtis, and all,

1+1 path protection with its "permanent bridging" is indeed the only 
1+case when SD measurements based on
packet loss can be applicable. It is not applicable in any other case IMO.
Consider the case when packets are dropped due to bit errors on some links:
longer packets will experience bit errors (and dropped by the FCS checks)
with higher probability than short packets, so if the traffic patterns on
the two paths are different, the SD measurements would be incomparable.)

Whether 1+1 path protection is a reasonable MPLS-TP technique is, IMO,
questionable.

But, at the very least, is worth to state explicitly that the SD concept
based on packet loss measurement has very limited applicability.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: Thursday, July 29, 2010 9:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Curtis,

Use of SD as trigger condition for protection does not result in moving the
traffic from the working connection to the protection connection. Refer to
my response to Sasha this morning. Traffic will stay on working connection
and will also be send over the protection connection.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 28 juli 2010 15:07
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

In message <[email-masked]>
Maarten Vissers writes:
>  
> Curtis,
>  
> SD is required to indicate packet loss. 
> There is no requirement to indicate packet loss due to bit errors on a 
> medium.
>  
> Regards,
> Maarten

If queueing loss causes traffic to move elsewhere, the queueing loss
is decreased and the queueing loss elsehwere can increase.

This can result in oscillations.  This did occur in the old DARPANET
in the mid 1980s (I think).  It is well know to be a Bad Idea (tm).

I hope we don't need a long thread on this.

Curtis

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: woensdag 28 juli 2010 14:15
> To: Alexander Vainshtein
> Cc: Maarten Vissers; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
>  
>  
> In message
> <[email-masked]>
> Alexander Vainshtein writes:
> >  
> > Maarten and all,
> > I have doubts regarding applicability of the SD concept to packet
networks
> in general and MPLS-TP in particular.
> > The problem is that, as opposed to traditional transport networks 
> > 9SONET/SDH, OTN etc.) packet loss depends on actual traffic. This is
> because one of the main reasons for dropping packets is congestion.
> > Note also that many types of packet traffic are backing off if they
> experience packet loss, and that routers employ WRED to prevent
synchronized
> loss of packets by multiple flows.
> >  
> > In other words, packet loss is very different from BER.
> >  
> > E.g., if you use packet los-based SD to trigger path protection in a 1:1
> (or N:1) model, you may simply find that your SD condition that have not
> been observed on the protection path before it was used (since it was not
> congested) appears there after you switch traffic to it in response to an
SD
> condition on the working path.
> >  
> > Regards,
> >      Sasha
>  
>  
> SD should not be used to indicate queueing loss.
>  
> Curtis
>  
>  
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Maarten Vissers
> > Sent: Tuesday, July 27, 2010 10:43 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
> >  
> >  
> > Hi Ma,
> >  
> > see inline..
> >  
> > ________________________________
> >  
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: dinsdag 27 juli 2010 4:53
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
> >  
> >  
> >  
> > Hi Maarten,
> >  
> > I have some questions about SD. Correct me if I'm wrong. Thanks!   
> >  
> > 1) Frame/Packet loss (per priority) of one path/channel is used for 
> > checking SD, but protection for path/channel does not base on one
> priority.
> >  
> > [maarten] At the moment the Ethernet OAM frame loss monitoring 
> > specifications in Y.1731 and G.8021 specify that ETH CCM is able to 
> > pro-actively monitor the frame loss in a VLAN for one priority and the 
> > in-service frames (i.e. the non drop-eligible frames at this 
> > priority). The operator can choose which priority it would like to 
> > monitor; typically the highest priority is assumed, but a lower 
> > priority (if present in the VLAN) is also possible.
> >  
> > [maarten] The frame loss monitoring in G.8021 will result in a DEG 
> > defect and this DEG defect will trigger the SD condition, which will 
> > be an input to the protection switching state machine.
> >  
> > [maarten] Note that on-demand frame loss monitoring is possible for 
> > every priority level in a VLAN.
> >  
> > [maarten] MEF has requested to extend the number of pro-active frame 
> > loss monitoring processes to be able to support frame loss monitoring 
> > for more then one priority in a VLAN. Y.1731 and G.8021 are currently 
> > being extended with this capability. I expect that this will also 
> > result in the definition of a DEG defect per priority and that SD will 
> > then be triggered by the oring of those DEG defects (e.g. SD = dDEG(p1)
or
> dDEG(p2) or .. or dDEG(pn)).
> > Note that frame loss is counted for in service frames, i.e. frames 
> > that are not drop-eligible.
> >  
> > [maarten] The potential extention of SD condition could increase 
> > complexity of protection switching while one could argue that loss of 
> > high priority frames is more severe then loss of low priority 
> > frames... to keep it simple it would be best to ignore such differences.
> >  
> > 2) in the future, maybe all packet links will run over OTN, but now, 
> > other interfaces(e.g. SDH, Ethernt) are being for thansport. It's 
> > worth to consider present state.
> >  
> > [maarten] I agree with you. 
> >  
> > Regards,
> > Maarten
> >  
> >  
> > Thanks! 
> >  
> > Regards,
> > Ma

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 01 Aug 2010 12:03:28 +0200

Hello Sasha,

You wrote:

> The "broadcast bridge" you mention is IMO something foreign to MPLS
 > (and, by implication, MPLS-TP) data plane.

I don't think so.

 > to be, generally speaking, different.

That is correct.
During an active protection switch, the broadcast bridge is exactly
the same as a permanent bridge.
The labels on the working path and on the protection path are always
different.
If you think broadcast bridge is foreign to MPLS(-TP) then also
permanent bridging is foreign.

> I will check the linear protection draft; if it refers to this
 > construct, I'd say it has serious problems.

Again, I don't agree with you, as explained above.

Regards, Huub.

> In message<[email-masked]>
> Maarten Vissers writes:
>>
>> Curtis,
>>

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Aug 2010 12:02:47 -0400

In message <[email-masked]>
Huub van Helvoort writes:
> That is correct.  During an active protection switch, the broadcast
> bridge is exactly the same as a permanent bridge.  The labels on the
> working path and on the protection path are always different.  If you
> think broadcast bridge is foreign to MPLS(-TP) then also permanent
> bridging is foreign.

It is not completely foreign in that GMPLS recovery specifies 1+1 as
an option.  It is however an option that AFAIK is only used with TDM
transport technologies such as SONET and OTN.  It is not used at all
(AFAIK) in packet networks.  In packet networks FRR is still
overwhelmingly dominant (if not completely dominant, with zero
bandwidth facilities backup paths being the norm, and rerouting taking
over after a few seconds).  Even though FRR is similar to GMPLS segment
protection, the latter may not be used at all in packet networks and
it may be safe to say that 1+1 is not used at all in MPLS networks,
since it is incredibly wasteful of capacity.

> Again, I don't agree with you, as explained above.

I do agree with Sasha on this.  We should take capabilities that are
*useful* from existing protection mechanism from other SDOs and get
rid of bad ideas in any existing protection mechanisms.

In other words, just because it is in a ITU-T document, doesn't make
it a good idea.  There is plenty of precidence for that.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Aug 2010 15:59:54 +0200

Curtis,

I agree with you that 1+1 protection of LSPs and PWs is not done in MPLS-TP
networks, and in general 1+1 protection is not done in packet networks.
Instead 1:1 protection is used. E.g. 1:1 PW protection, 1:1 LSP protection.
1:1 protection can be operated with either a "selector bridge" or a
"broadcast bridge".

But the use of a "broadcast bridge" in 1:1 protection is not the same as 1+1
protection. 
In 1:1 protection with broadcast bridge:
1) for case working path is OK, traffic is send over working path only; no
traffic on protection path
2) for case working path is in SD, traffic is send over both working path
and protection path for the duration of the SD condition.
1:1 protection with braodcast bridge is **not** "incredibly wasteful of
capacity". As you described in your current practices email, network is
architected such that there will not be congestion of preferred traffic
after recovery of a single fault; i.e. after sending some of the traffic in
the network over its protection paths during a SF or SD condition.

Note that "broadcast bridge" is also used in OTN 1:1 ODU SNCP (G.873.1) and
in SDH 1:n MSP (G.841).
Note that "broadcast bridge" is **not** used in SDH 1+1 VC SNCP and OTN 1+1
ODU SNCP.

FRR based protection seems to be insufficient for MPLS-TP networks, and that
is the reason we work on 1:1 PW and LSP protection. There is a requirement
to protect those PWs and LSPs also on a SD condition (is FRR having an SD
condition?), and it is necessary to continue the detection of the SD
condition after the protection switch action which restores the traffic. The
same applies also for protection after a SF condition; monitoring of SF
condition must continue after a protection switch action.

As long as an SD condition is determined on the basis of the actual
committed traffic, it is necessary to keep this traffic on the working path.
Only if SD is determined on synthetic packets (i.e. on OAM packets), it may
be possible to remove this traffic from the working path when swithcing to
the protection path (i.e. use of "selector bridge").

So operators have a choice:
1) measure loss of actual preferred traffic packets ==> use 1:1 broadcast
bridge
2) measure loss of synthetic traffic packets (i.e. OAM) ==> use 1:1 selector
bridge.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: maandag 2 augustus 2010 18:03
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

> think broadcast bridge is foreign to MPLS(-TP) then also permanent 

It is not completely foreign in that GMPLS recovery specifies 1+1 as an
option.  It is however an option that AFAIK is only used with TDM transport
technologies such as SONET and OTN.  It is not used at all
(AFAIK) in packet networks.  In packet networks FRR is still overwhelmingly
dominant (if not completely dominant, with zero bandwidth facilities backup
paths being the norm, and rerouting taking over after a few seconds).  Even
though FRR is similar to GMPLS segment protection, the latter may not be
used at all in packet networks and it may be safe to say that 1+1 is not
used at all in MPLS networks, since it is incredibly wasteful of capacity.

I do agree with Sasha on this.  We should take capabilities that are
*useful* from existing protection mechanism from other SDOs and get rid of
bad ideas in any existing protection mechanisms.

In other words, just because it is in a ITU-T document, doesn't make it a
good idea.  There is plenty of precidence for that.

Curtis

> > In Ethernet and MPLS-TP type packet transport networks we use 1:1 
> > SNC/S protection with a "broadcast bridge". Note that a "broadcast 
> > bridge" is not the same as a "permanent bridge" used in 1+1 SNC
protection.
> >
> > A "broadcast bridge" sends under non-SF/SD conditions traffic to the 
> > working connection only. Only during SF or SD conditions the traffic 
> > is send to both the working and the protection connections. This 
> > implies that traffic is send to both working and protection 
> > connections for a few hours per year only (assuming a typical MTTR of
about 4 hours).
> >
> > A "permanent bridge" send traffic under all conditions to both 
> > working and protection connections. In packet transport networks 
> > (Ethernet, MPLS-TP) such "permanent bridge" would be used only for 
> > 1+1 unidirectional p2mp SNC/N protected LSPs or PWs. The 
> > unidirectional nature of the p2mp connections require for the case 
> > of protection that both working and protection connections carry the 
> > traffic so that the tail end (i.e. leaf nodes) can perform the
protection switching locally.
> > longer packets will experience bit errors (and dropped by the FCS 
> > checks) with higher probability than short packets, so if the 
> > traffic patterns on the two paths are different, the SD measurements 
> > would be incomparable.)
> >
> > Whether 1+1 path protection is a reasonable MPLS-TP technique is, 
> > IMO, questionable.
> >
> > But, at the very least, is worth to state explicitly that the SD 
> > concept based on packet loss measurement has very limited applicability.
> >
> > Regards,
> >       Sasha
> >
> >
> > Use of SD as trigger condition for protection does not result in 
> > moving the traffic from the working connection to the protection 
> > connection. Refer to my response to Sasha this morning. Traffic will 
> > stay on working connection and will also be send over the protection
connection.
> >> There is no requirement to indicate packet loss due to bit errors 
> >> on a medium.
> >>
> >> Regards,
> >> Maarten
> >
> >
> >> (or N:1) model, you may simply find that your SD condition that 
> >> have not been observed on the protection path before it was used 
> >> (since it was not
> >>> From: [email-masked] [mailto:[email-masked]] 
> >>> On Behalf Of Maarten Vissers
> >>> 1) Frame/Packet loss (per priority) of one path/channel is used 
> >>> for checking SD, but protection for path/channel does not base on 
> >>> one
> >> priority.
> >>>
> >>> specifications in Y.1731 and G.8021 specify that ETH CCM is able 
> >>> to pro-actively monitor the frame loss in a VLAN for one priority 
> >>> and the in-service frames (i.e. the non drop-eligible frames at 
> >>> this priority). The operator can choose which priority it would 
> >>> like to monitor; typically the highest priority is assumed, but a 
> >>> lower priority (if present in the VLAN) is also possible.
> >>>
> >>> defect and this DEG defect will trigger the SD condition, which 
> >>> will be an input to the protection switching state machine.
> >>>
> >>> [maarten] Note that on-demand frame loss monitoring is possible 
> >>> for every priority level in a VLAN.
> >>>
> >>> [maarten] MEF has requested to extend the number of pro-active 
> >>> frame loss monitoring processes to be able to support frame loss 
> >>> monitoring for more then one priority in a VLAN. Y.1731 and G.8021 
> >>> are currently being extended with this capability. I expect that 
> >>> this will also result in the definition of a DEG defect per 
> >>> priority and that SD will then be triggered by the oring of those 
> >>> DEG defects (e.g. SD = dDEG(p1)
> > or
> >>> complexity of protection switching while one could argue that loss 
> >>> of high priority frames is more severe then loss of low priority 
> >>> 2) in the future, maybe all packet links will run over OTN, but 
> >>> now, other interfaces(e.g. SDH, Ethernt) are being for thansport. 
> >>> It's worth to consider present state.
> >>>