[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and meth-05

 
Hi Kris, Did not realize until now that we had not responded to your
comments on the term draft.

Cheers,
Jay

> -----Original Message-----
> From: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On Behalf 
> Of Kris Michielsen (kmichiel)
> Sent: Monday, August 03, 2009 9:56 AM
> To: 'Al Morton'; bmwg at ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and
> meth-05
> 
> Hi,
> 
> Please find some comments/questions below.
> 
> 
> comments on term-06:
> 
> * The definitions don't seem to be consistent. A "Path" is defined in 
> the draft as a sequence of nodes/links from R1 (ingress of IP
> packets) and Rn (egress of IP packets). Other definitions in the draft

> point out that a "Backup Path" is not necessarily end-to-end, but can 
> start and end at any node along the "Primary Path". If the Backup Path

> is not end-to-end, one can also not claim that the Backup Path becomes

> the Working Path upon a Failover Event.

Kris, as you are well aware, the backup path originates at the PLR and
terminates on a Merge point that is not necessarily an egress node. That
is all we are trying to point out here.


> * It needs to be made clear that the definitions of the different 
> paths are not applicable to MPLS TE LSPs. The definition of a path in 
> the draft is a physical sequence of nodes/links, while a TE LSP is a 
> logically signalled path. A headend may resignal a new TE LSP 
> following a failure. This new TE LSP may in general follow another 
> sequence of nodes/links and may possibly no longer be routed over the 
> "backup TE LSP" while the failed link/node is still not restored.

Not sure if we need to add any further clarification. The new TE LSP
again would traverse a physical sequence of nodes/links.

> 
> * I think it is difficult to distinguish Failover Events (for sub-IP) 
> from Convergence Events (for IGP). The distinction is possible for
e.g.
> SONET APS. But how do we distinguish the two for e.g. MPLS TE FRR? A 
> link or node failure will trigger IGP convergence as well in that case

> and could potentially result in additional packet loss.
> 

Fair question. Typically the timer values of IGPs are not so granular
that they would converge prior to the Failover.

> * The Benchmarks (3.5) give no detail about which packet loss needs to

> be observed. Is it for traffic going over all Primary Paths, or a 
> single Primary Path? Is it to a single destination reachable over a 
> Primary Path or all destinations reachable over a Primary Path?

All destinations reachable over a Primary Path. It is upto the tester to
choose single or all Primary Path.

> 
> * The definition of Failover Packet Loss (3.5.1) doesn't need to point

> out start and end of traffic loss, how the start end end are defined 
> doesn't seem right anyway (not for multiple streams anyway). I think 
> it is important to take the time between Failover Event and first 
> observed packet loss as well in case the failure does not cause 
> instantaneous packet loss. Shouldn't there be a "Sustained Failover 
> Validation Time", i.e. a period in which there is no aditional packet 
> loss before declaring Failover as completed?

We don't see a need for Sustained Failover Validation Time. But would
like to understand the need for this better. Would you be available for
a quick call ?

> 
> * What are the definitions of the "Time(xxx)" terms used in 3.6.1?
>

They are defined in section 3.5
 
> * It needs to be pointed out that the PLBM gives the _average_ loss 
> over the measured destinations.
> 

This can be done. We will point it out.