Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

From: "Shahram Davari" <[email-masked]>
Date: Tue, 1 Mar 2011 11:54:57 -0800

Hi,

I would like to support the disabling of Poll/Final for MPLS-TP LSP BFDs. Transport networks don't need to change the rates and are mostly static. Also Poll/Final will most likely require extra Software in addition to HW, which can increase complexity and cost for MPLS-TP operation.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Thursday, February 10, 2011 6:38 AM
To: David Allan I
Cc: [email-masked]; [email-masked]; Robert Rennison
Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Dave, and all,
To avoid any misinterpretation, please consider the original email as my LC comment.

Regards,
     Sasha

-----Original Message-----
From: Alexander Vainshtein 
Sent: Thursday, February 10, 2011 1:36 PM
To: 'David Allan I'
Cc: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; Robert Rennison
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Dave and all,
I'd like to remind you that Rob and I have already questioned the decision to change the BFD state machine by disabling in some case the Poll/Final sequence.

The situation as presented in the draft seems to introduce even more problems. 
E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but follows the procedures specified in RFC 5880 and 5881 which, to the best of my understanding, include usage of Poll/Final sequence.

It is my understanding that BFD for an MPLS-TP LSP would look exactly as BFD in VCCV (including the same code point).
If this is correct, how should the implementation distinguish between "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they seem to be prohibited?

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Thursday, February 10, 2011 1:09 PM
To: Mach Chen; 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Hi Mach: 

Thanks for the review

>I read the draft, here are some comments, please consider:

>1.Section 3.5, last sentence of first paragraph

>"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD."
>There is a "be" lost between "can" and "only".

Good catch, will fix.

>2.Section 3.5.2
>"1. BFD control packets are received with an unexpected encapsulation (mis-connectivity defect), these include: 
>          - a PW receiving a packet with a GAL", Since GAL can be used 
>for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00), this should not be a defect. Suggest to remove it.

We'll review and edit accordingly.

>3 Section 3.5.2
>" 4. Receipt of an expected session discriminator with an unexpected label (mis-connectivity defect).", For a receiver, how does it know that the session >discriminator is valid but the label is invalid? IMHO, this defect is just another description of defect 3 . Suggest to remove it.

If the session discriminator exists in the BFD database, it is superficially a valid descriminator but the label of arrival can be incorrect. This may indicate an implementation problem at the source MEP. What we were referring to in '3' was a session discriminator that did not exist in the local database, BFD had never handed it out hence it could not be found.

>4.Section 3.5.4.2
>" Exit from a misconfiguration defect occurs when two consecutive CC or 
>CV frames have been received with the expected M bit setting." IMHO, this sentence is little bit vague, and since this draft only defines for P2P LSP, why not just say "...with M bit clear."

OK

>5. Section 3.5.4.3
>"Exit from a mis-connectivity defect state occurs when no CV messages 
>have been received with an incorrect source MEP-ID for a period of 3.5 seconds.", since there are several defects listed in Section 3.5.2 and this is only one condition for exiting from a mis-connectivity defect state. How about "Exit >from a mis-connectivity defect state occurs when no CV messages with mis-connectivity defects have been received for a period of 3.5 seconds "

That seems to be more accurate, I'd replace "with...." with "indicating an on-going mis-connectivity defect has been....". Simply wordsmithing.

>6. Section 3.5.5

>In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for DOWN state.

Good catch. Will fix

Cheers
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: Thursday, February 03, 2011 10:14 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls-tp] mpls wg last call on
> draft-ietf-mpls-tp-cc-cv-rdi-03
> 
> Working Group,
> 
> this is to start a four week working group last call on "Proactive 
> Connectivity Verification, Continuity Check and Remote Defect 
> indication for MPLS Transport Profile"
> (draft-ietf-mpls-tp-cc-cv-rdi-03.txt).
> 
> Please send comments to the [email-masked] mailing list.
> 
> This working group last call ends on February 28, 2011.
> 
> 
> Loa, George and Ross
> 
> MPLS wg co-chairs
> --
> 
> 
> Loa Andersson                         email:
> [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 1 Mar 2011 12:29:52 -0800

Dear Shahram, Sasha and All,
I support current wording of the first para in Section 3.5. to address
Sasha's concern regarding distinguishing MPLS CC message from BFD over VCCV
per RFC 5885 the last sentence might be changed to like:
"Poll/final discipline can be only used for VCCV and UDP/IP encapsulated BFD
when using unique appropriate Associated Channel type."
I believe that lately there was sufficient discussion about compatibility of
BFD-based CC OAM and BFD over VCCV. AFAIK, there's no requirement to support
backward compatibility and that might be stated in the document.

Regards,
Greg

On Tue, Mar 1, 2011 at 11:54 AM, Shahram Davari <[email-masked]> wrote:

> Hi,
>
> I would like to support the disabling of Poll/Final for MPLS-TP LSP BFDs.
> Transport networks don't need to change the rates and are mostly static.
> Also Poll/Final will most likely require extra Software in addition to HW,
> which can increase complexity and cost for MPLS-TP operation.
>
> Regards,
> Shahram
>
> I'd like to remind you that Rob and I have already questioned the decision
> to change the BFD state machine by disabling in some case the Poll/Final
> sequence.
>
> E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation but
> follows the procedures specified in RFC 5880 and 5881 which, to the best of
> my understanding, include usage of Poll/Final sequence.
>
> It is my understanding that BFD for an MPLS-TP LSP would look exactly as
> BFD in VCCV (including the same code point).
> If this is correct, how should the implementation distinguish between "PWE3
> mode" (where poll/final are used) and "MPLS-TP mode where they seem to be
> prohibited?
>
> Regards,
>     Sasha
>
> >"1. BFD control packets are received with an unexpected encapsulation
> (mis-connectivity defect), these include:
> >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-00),
> this should not be a defect. Suggest to remove it.
>
> >" 4. Receipt of an expected session discriminator with an unexpected label
> (mis-connectivity defect).", For a receiver, how does it know that the
> session >discriminator is valid but the label is invalid? IMHO, this defect
> is just another description of defect 3 . Suggest to remove it.
>
> If the session discriminator exists in the BFD database, it is
> superficially a valid descriminator but the label of arrival can be
> incorrect. This may indicate an implementation problem at the source MEP.
> What we were referring to in '3' was a session discriminator that did not
> exist in the local database, BFD had never handed it out hence it could not
> be found.
>
> >4.Section 3.5.4.2
> >CV frames have been received with the expected M bit setting." IMHO, this
> sentence is little bit vague, and since this draft only defines for P2P LSP,
> why not just say "...with M bit clear."
>
> OK
>
> >5. Section 3.5.4.3
> >have been received with an incorrect source MEP-ID for a period of 3.5
> seconds.", since there are several defects listed in Section 3.5.2 and this
> is only one condition for exiting from a mis-connectivity defect state. How
> about "Exit >from a mis-connectivity defect state occurs when no CV messages
> with mis-connectivity defects have been received for a period of 3.5 seconds
> "
>
> That seems to be more accurate, I'd replace "with...." with "indicating an
> on-going mis-connectivity defect has been....". Simply wordsmithing.
>
> >6. Section 3.5.5
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 2 Mar 2011 15:36:54 +0200

Shahram and all,
Please see some comments inline below.

Regards,
     Sasha

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, March 01, 2011 9:55 PM
> To: Alexander Vainshtein; David Allan I
> I would like to support the disabling of Poll/Final for MPLS-TP LSP
> BFDs. Transport networks don't need to change the rates and are mostly
> static. 
[[[Sasha]]] There are two different statements here IMO:

1. "Transport networks do not have to change the rates".
   Sounds very much like "transport networks are always single-vendor" to me.
   Because in a multi-vendor environment you have to deal with different rate ranges
   And have from time to time manipulate these rates...

2. "Transport networks are mostly static".
   I do not really understand how this is related to the subject.  

Also Poll/Final will most likely require extra Software in
> addition to HW, which can increase complexity and cost for MPLS-TP
> operation.
[[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to the operators.
And the vendors who have implemented Poll/Final will have to go into 
new development and support two different BFD state machines... if this is not expensive, what is?
> I'd like to remind you that Rob and I have already questioned the
> decision to change the BFD state machine by disabling in some case the
> Poll/Final sequence.
> 
> E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP encapsulation
> but follows the procedures specified in RFC 5880 and 5881 which, to the
> best of my understanding, include usage of Poll/Final sequence.
> 
> It is my understanding that BFD for an MPLS-TP LSP would look exactly
> as BFD in VCCV (including the same code point).
> If this is correct, how should the implementation distinguish between
> "PWE3 mode" (where poll/final are used) and "MPLS-TP mode where they
> seem to be prohibited?
> 
> Regards,
>      Sasha
> 
> >for PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-
> 00), this should not be a defect. Suggest to remove it.
> 
> >" 4. Receipt of an expected session discriminator with an unexpected
> label (mis-connectivity defect).", For a receiver, how does it know
> that the session >discriminator is valid but the label is invalid?
> IMHO, this defect is just another description of defect 3 . Suggest to
> remove it.
> 
> incorrect. This may indicate an implementation problem at the source
> MEP. What we were referring to in '3' was a session discriminator that
> did not exist in the local database, BFD had never handed it out hence
> it could not be found.
> 
> >4.Section 3.5.4.2
> >CV frames have been received with the expected M bit setting." IMHO,
> this sentence is little bit vague, and since this draft only defines
> for P2P LSP, why not just say "...with M bit clear."
> 
> OK
> 
> >5. Section 3.5.4.3
> seconds.", since there are several defects listed in Section 3.5.2 and
> this is only one condition for exiting from a mis-connectivity defect
> state. How about "Exit >from a mis-connectivity defect state occurs
> when no CV messages with mis-connectivity defects have been received
> for a period of 3.5 seconds "
> 
> That seems to be more accurate, I'd replace "with...." with "indicating
> an on-going mis-connectivity defect has been....". Simply wordsmithing.
> 
> >6. Section 3.5.5
>

---

From: Robert Rennison <[email-masked]>
Date: Thu, 31 Mar 2011 05:01:42 -0400

Authors,

The Poll/Final issue is still open with this document and I'd like to  reiterate one point  but also  understand  a  technicality/feasibility
 
1. An observation/ objection: It becomes yet another configuration subtly / scope for error in needing to know" does the remote end of this PW support P/F or not".  Additionally we are now changing the  BFD state machine  and complicating things to pander to the "perception" that P/F is _unnecessarily_ complex.

Ok Off soapbox, now to my question. I'd like to understand how folks who want to run without the P/F mechanism envisage things working.

If both ends can permanently "blast" at the preconfigured rate and set the STA bits to say Init (what the Sta should be set to for this always fixed rate should be made clear) then I can see how both ends will transition to "Up" and this is what I figured was how things would happen. However; in more careful reading of the draft I see the following  contradictory statements.

3.5. BFD Profile for MPLS-TP 

   BFD MUST operate in asynchronous mode. In this mode, the BFD Control 
   packets are periodically sent at configurable time rate. This rate is 
   typically a _fixed_ value for the lifetime of the session. In the rare 
   circumstance where an operator has a reason to change session 
   parameters, the session MUST be moved to the ADMIN DOWN state. 
   Poll/final discipline can only used for VCCV and UDP/IP encapsulated 
   BFD.

Here we are saying things are sent at a fixed rate.

------------
3.5.1. Session initiation 
....

   Otherwise once a transition from DOWN to INIT has occurred, the 
   session progresses as per [4]. In both the DOWN and INIT states 
   messages are transmitted at a rate of one per second and the defect 
   detection interval is fixed at 3.5 seconds. On transition to the UP 
   state, message periodicity  _changes to_ the negotiated and/or 
   configured rate and the detect interval switches to detect multiplier 
   times the session peer's Tx Rate
------------

Here we are talking about the rate changing to the configured rate, and there is no distinguishing between whterh P/F is used or not;  it's this change of rate  that I cannot see easily working without the P/F

Paradoxically the so called "complex"  poll/final is necessary not just to change the rate  due to some operational nicety but to allow us to coordinate any rate changes, it's your friend once you understand it. Given the above statement of starting at some slow rate there will always need to be a rate change to get to any values other than a Tx interval of 1 second.

Let's say I've made the transition from DOWN to INIT based on the reception of a BFD control packet from the remote end. I now transition to the UP state when receiving the next packet, I'm now expecting him to start sending at the negotiated rate, however, in the absence of  the remote end setting the F bit to indicate he has programmed his HW to start sending at the preconfigured rate, I may unfairly/ prematurely declare the session down if he has not jumped into UP state himself. Likewise the remote end may have this problem with my transition too.

In short, notwithstanding my objection to lack of P/F I'd like some further clarification regarding how the rate change  mechanism specified in the last para of 3.5.1 is expected to work without P/F.  Or perhaps this para is in error since it's  inconsistent with the  first para of 5.1 stating things remain at a fixed rate.

Cheers

Rob Rennison

-----Original Message-----
From: Alexander Vainshtein 
Sent: Wednesday, March 02, 2011 8:37 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; Robert Rennison; David Allan I
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Shahram and all,

Regards,
     Sasha

---

From: David Allan I <[email-masked]>
Date: Thu, 31 Mar 2011 05:09:44 -0400

Hi Rob:

The first paragraph of 3.5.1 describes the initialization. The intent is that an implementation that cannot support the requested periodicity in the INIT request will not transition from DOWN to INIT and returns a diagnostic code accordingly. The premise is that the periodicity is a business requirement hence the negotiation is binary.

As for the contradictory statements, it is a fixed rate for the UP state for the life of the session would be more precise wording....

Hope this helps
Dave

-----Original Message-----
From: Robert Rennison [mailto:[email-masked]] 
Sent: Thursday, March 31, 2011 11:02 AM
To: Alexander Vainshtein; Shahram Davari
Cc: [email-masked]; David Allan I
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues

Authors,

------------

Cheers

Rob Rennison

-----Original Message-----
From: Alexander Vainshtein
Sent: Wednesday, March 02, 2011 8:37 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; Robert Rennison; David Allan I
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03

Shahram and all,

Regards,
     Sasha

[[[Sasha]]] Extra SW (as opposed to extra HW) usually doesn't cost to the operators.
And the vendors who have implemented Poll/Final will have to go into new development and support two different BFD state machines... if this is not expensive, what is?
> but follows the procedures specified in RFC 5880 and 5881 which, to 
> the best of my understanding, include usage of Poll/Final sequence.
> 
> >          - a PW receiving a packet with a GAL", Since GAL can be 
> >used for 
> >PW(http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-
> That seems to be more accurate, I'd replace "with...." with 
> "indicating an on-going mis-connectivity defect has been....". Simply wordsmithing.
> 
> >6. Section 3.5.5
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Mar 2011 11:14:51 +0200

Rob, Dave and all,
The question raised by Rob remains unanswered IMHO:

How does the side transiting from Init to Up know when to change its detection interval 
from 3.5 seconds to the interval that matches the configured tx rate of the peer?

If this is done too soon, false LOC will be detected, and it will result in unnecessary protection switching etc...

P/F is one way to resolve this issue. To the best of my understanding, no alternative has been proposed so far...

Regards,
     Sasha

> From: David Allan I [mailto:[email-masked]]
> Sent: Thursday, March 31, 2011 11:10 AM
> To: Robert Rennison; Alexander Vainshtein; Shahram Davari
> Cc: [email-masked]
> The first paragraph of 3.5.1 describes the initialization. The intent
> is that an implementation that cannot support the requested periodicity
> in the INIT request will not transition from DOWN to INIT and returns a
> diagnostic code accordingly. The premise is that the periodicity is a
> business requirement hence the negotiation is binary.
> 
> As for the contradictory statements, it is a fixed rate for the UP
> state for the life of the session would be more precise wording....
> 
> Hope this helps
> Dave
> 
> 
> 
> The Poll/Final issue is still open with this document and I'd like to
> reiterate one point  but also  understand  a  technicality/feasibility
> 
> 1. An observation/ objection: It becomes yet another configuration
> subtly / scope for error in needing to know" does the remote end of
> this PW support P/F or not".  Additionally we are now changing the  BFD
> state machine  and complicating things to pander to the "perception"
> that P/F is _unnecessarily_ complex.
> 
> Ok Off soapbox, now to my question. I'd like to understand how folks
> who want to run without the P/F mechanism envisage things working.
> 
> If both ends can permanently "blast" at the preconfigured rate and set
> the STA bits to say Init (what the Sta should be set to for this always
> fixed rate should be made clear) then I can see how both ends will
> transition to "Up" and this is what I figured was how things would
> happen. However; in more careful reading of the draft I see the
> following  contradictory statements.
> 
> Here we are talking about the rate changing to the configured rate, and
> there is no distinguishing between whterh P/F is used or not;  it's
> this change of rate  that I cannot see easily working without the P/F
> 
> Paradoxically the so called "complex"  poll/final is necessary not just
> to change the rate  due to some operational nicety but to allow us to
> coordinate any rate changes, it's your friend once you understand it.
> Given the above statement of starting at some slow rate there will
> always need to be a rate change to get to any values other than a Tx
> interval of 1 second.
> 
> Let's say I've made the transition from DOWN to INIT based on the
> reception of a BFD control packet from the remote end. I now transition
> to the UP state when receiving the next packet, I'm now expecting him
> to start sending at the negotiated rate, however, in the absence of
> the remote end setting the F bit to indicate he has programmed his HW
> to start sending at the preconfigured rate, I may unfairly/ prematurely
> declare the session down if he has not jumped into UP state himself.
> Likewise the remote end may have this problem with my transition too.
> 
> In short, notwithstanding my objection to lack of P/F I'd like some
> further clarification regarding how the rate change  mechanism
> specified in the last para of 3.5.1 is expected to work without P/F.
> Or perhaps this para is in error since it's  inconsistent with the
> first para of 5.1 stating things remain at a fixed rate.
> 
> Cheers
> 
> Rob Rennison
> 
> 
> > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-
> tp-
> > cc-cv-rdi-03
> >
> > Hi,
> >
> > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-
> tp-
> > cc-cv-rdi-03
> >
> > Dave, and all,
> > Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-
> tp-
> > cc-cv-rdi-03
> >
> > Dave and all,
> > Subject: Re: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-
> tp-
> > cc-cv-rdi-03
> >
> >
> >
> > Hi Mach:
> >
> > Thanks for the review
> >
> > >"Poll/final discipline can only used for VCCV and UDP/IP
> encapsulated
> > BFD."

---

From: David Allan I <[email-masked]>
Date: Thu, 31 Mar 2011 05:25:10 -0400

Hi:

A further clarification would be that upon receipt of UP from the peer MEP would be the time to change the detect mult to 3.5*rxinterval. That would be the point where the far end changed its periodicity from 1/sec to rxinterval, and would avoid the potential race condition you describe....

I'll treat this discussion as LC comments requiring clarification for now...

D

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Thursday, March 31, 2011 11:15 AM
To: David Allan I; Robert Rennison
Cc: [email-masked]; Shahram Davari
Subject: RE: [mpls] [mpls-tp] mpls wg last call on draft-ietf-mpls-tp-cc-cv-rdi-03: Poll /Final Issues

Rob, Dave and all,

How does the side transiting from Init to Up know when to change its detection interval from 3.5 seconds to the interval that matches the configured tx rate of the peer?

Regards,
     Sasha

> is that an implementation that cannot support the requested
> periodicity in the INIT request will not transition from DOWN to INIT
> and returns a diagnostic code accordingly. The premise is that the
> periodicity is a business requirement hence the negotiation is binary.
>
> this PW support P/F or not".  Additionally we are now changing the
> BFD state machine  and complicating things to pander to the "perception"
> the STA bits to say Init (what the Sta should be set to for this
> always fixed rate should be made clear) then I can see how both ends
> will transition to "Up" and this is what I figured was how things
> would happen. However; in more careful reading of the draft I see the
> Here we are talking about the rate changing to the configured rate,
> and there is no distinguishing between whterh P/F is used or not;
> it's this change of rate  that I cannot see easily working without the
> P/F
>
> Paradoxically the so called "complex"  poll/final is necessary not
> just to change the rate  due to some operational nicety but to allow
> us to coordinate any rate changes, it's your friend once you understand it.
> reception of a BFD control packet from the remote end. I now
> transition to the UP state when receiving the next packet, I'm now
> expecting him to start sending at the negotiated rate, however, in the
> absence of the remote end setting the F bit to indicate he has
> programmed his HW to start sending at the preconfigured rate, I may
> unfairly/ prematurely declare the session down if he has not jumped into UP state himself.
> > E.g., RFC 5885 allows to run BFD in VCCV without UDP/IP
> > encapsulation but follows the procedures specified in RFC 5880 and
> > 5881 which, to the best of my understanding, include usage of Poll/Final sequence.
> >
> > It is my understanding that BFD for an MPLS-TP LSP would look
> > exactly as BFD in VCCV (including the same code point).
> > >" Exit from a misconfiguration defect occurs when two consecutive
> > >CC
> > or
> > this is only one condition for exiting from a mis-connectivity
> > defect state. How about "Exit >from a mis-connectivity defect state
> > occurs when no CV messages with mis-connectivity defects have been
> > received for a period of 3.5 seconds "
> >
> > "indicating an on-going mis-connectivity defect has been....".
> > Simply
> wordsmithing.
> >
> > >6. Section 3.5.5
> >
> > >In Figure 5, seems that it is lack of "AIS-LDI, LKR" inputs for
> > >DOWN
> > state.
> >
> > Good catch. Will fix
> >
> > Cheers
> > Dave
> >
> >
> >
> > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf Of Loa Andersson