Subject: [mpls-tp] Comment on draft-ietf-mpls-tp-cc-cv-rdi-00

From: Lavanya Srivatsa <[email-masked]>
Date: Fri, 2 Jul 2010 13:49:03 +0530

Hello authors of the draft,

The cc-cv draft states in section 3.4 :

"When on a ME the CC or proactive CV functionality is disabled, the

 BFD session transitions to the ADMIN DOWN State and the BFD session

 ends.

 A new BFD session is initiated when the operator enables or re-
  enables the CC or CV functionality on the same ME."

Is this not in contradiction to the base draft which talks about sending BFD control packets even in ADMIN DOWN state (section 6.8.16) and for holding down sessions (section 6.8.18) in the Admin Down state? From what I interpret from these 2 sections is that the Down state and the Admin Down state are to be treated likewise and BFD control packets would continue to be exchanged.

Moreover, IMHO, if the session itself is brought down/ends upon disable, then there would be no need for an Admin Down state in the first place. For a session to remain in the Admin Down state, the session must exist. So there would be no need to create a new BFD session on re-enable.

Can you please clarify?

- Lavanya

---

From: Mahesh Akula <[email-masked]>
Date: Tue, 6 Jul 2010 23:06:07 -0700

Hi Lavanya,

As there seems to be no reply from the authors, replying based on my
understanding. Pls see inline [MA]

On Fri, Jul 2, 2010 at 1:19 AM, Lavanya Srivatsa <
[email-masked]> wrote:

> “When on a ME the CC or proactive CV functionality is disabled, the
>
>   enables the CC or CV functionality on the same ME.”
>
>
>
> Is this not in contradiction to the base draft which talks about sending
> BFD control packets even in ADMIN DOWN state (section 6.8.16) and for
> holding down sessions (section 6.8.18) in the Admin Down state? From what I
> interpret from these 2 sections is that the Down state and the Admin Down
> state are to be treated likewise and BFD control packets would continue to
> be exchanged.
>

MA: I don't think bfd base draft mandates that the BFD control packets still
be sent when session moves to ADMIN DOWN state. It does suggests that
"BFD Control packets SHOULD be transmitted for at least a Detection
   Time after transitioning to AdminDown state in order to ensure that
   the remote system is aware of the state change"

>
>
> Moreover, IMHO, if the session itself is brought down/ends upon disable,
> then there would be no need for an Admin Down state in the first place. For
> a session to remain in the Admin
>
Down state, the session must exist. So there would be no need to create a
new BFD session on re-enable.

 [MA]: IMO, difference between the Admin down state and Down State is not
about the exchanging of the BFD control packets or holding the session, it
is how the BFD application at the peer reacts on receiving such a state
change notification, right?

Regards,
Mahesh

>
>
> Can you please clarify?
>
>
>
> - Lavanya
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
>