Re: [mpls] Issues with draft-ietf-mplt-tp-cc-cv-rdi-01 relating to becoming a WG document...

Dear Dave,
I welcome your statement:
" We will have a "profile" of BFD just like we have a "profile" of MPLS."
And the draft-ietf-mpls-tp-cc-cv-01 in many aspects clearly identifies this
superset. My concern, as we've discussed on the list, is that some BFD-base
functionality inherited by BFD-based MPLS-TP OAM not for technical reason
but for the sake of "existing implementations". Risking to repeat arguments
already made, I'd propose to make timer change possible only through
AdminDown state. Though that changes the BFD-base behavior, it would be, in
my view, appropriate for the profile.

Regards,
Greg

On Tue, Jul 27, 2010 at 12:24 AM, David Allan I
<david.i.allan@ericsson.com>wrote:

> Hi
>
> The existence of unresolved comments was raised yesterday. I thought the
> comments raised had been dealt with at the time by a post from co-author
> John Drake.....
>
> Apparently that must have been missed, Here is a reiteration....
>
> The issues raised were:
>
> 1) running BFD at a fixed operator's configurable rate.
> Nothing in the draft precludes this.
>
> 2) Unidirectional path support
> It is noted as FFS and dependent on a uni-directional BFD solution which
> would involve reviving the p2mp BFD draft. As adopting as a WG document is
> indication of intent to progress and finish the work, not a statement of
> completeness, and use of BFD is consistent with existing agreements on how
> to proceed, although a legit concern I'd assume it is not gating.
>
> 3) One mechanism that can work independently from the protection switching
> configuration.
> This comment was addressed as the modes (BFD as it exists, and BFD as
> extended for TP) have been decoupled from any suggestion of use cases.
>
> Based on comments yesterday at the mike and on the list in the past, I'd
> assume the issue folks actually have is that BFD is a superset of the
> required functionality. That comes with the territory. We will have a
> "profile" of BFD just like we have a "profile" of MPLS. It is not clear to
> me that this is well understood.
>
> Is there anything else that was missed?
> Cheers
> Dave
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>