Subject: [mpls] team to drive a BFD based solution for CC, CV and RDI

From: Loa Andersson <[email-masked]>
Date: Fri, 09 Apr 2010 10:47:07 +0200

All,

For some time the mpls working group chairs have been very
concerned about the lack of progress on a BFD based solution
for CV, CC and RDI.

To improve on this situation the working group chairs have decided
to create a team modeled after how we worked with the LDP specification
when we started up the MPLS work.

The new team will work based on a mandate from the working group
chairs, with clear instructions progress the draft in such a way
that author contributions are recognized, that the IETF expertise
on BFD is involved and to seek a quick rough consensus among the
authors.

Note that this means that the people currently involved in the
draft-asm remain as authors.

We will therefore have one team of editors consisting of

Dave Allan
George Swallow
John Drake

That is mainly responsible for driving the effort and make
sure that we are making good progress.

The full team of authors will also include the
current authors of the document, i.e.:

Sami Boutros
Annamaria Fulignoli
Martin Vigoureux
Siva Sivabalan
David Ward

/Loa

-- 

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

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 11 Apr 2010 17:17:58 -0700

Hi Loa,

Thanks for bringing this UP. I see a lot of basic gaps in the spec. On
a first read this is what I found:

1. I did not understand why we have a seperate CC and CC/CV mode. In
other words when would CV not be required? Some justification on why
some decisions have been taken would be helful, rather than just the
packet formats.

2. If we have CV it is good to be able to allow different packet sizes
te test a packet. So the packet should be like:

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|     Flags     |0xHH  MPLS-TP CV/CC Code Point |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ACH TLV Header                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~          Unique MEP-ID of source of the BFD packet            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                  BFD Control Packet                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. For BFD profile for MPLS-TP we should probably clarify that echo
function in the asynch mode is not supported.

4. I think an error BFD packet should not bring the BFD session to
down. The draft states that:

   On a Sink MEP, a BFD session is declared Down if one of the following
   defects identified by the proactive CC-CV functions occurs:
     - an unexpected globally unique Source MEP identifier is received

An error BFD packet in my view should be discraded and the respective
conutners need to be updated.

5. The Admin Down state section unnecessarily confuses/ breaks the BFD
specification (for bidirectional sessions). It states that:

   When the MEP source function is disabled, BFD Control packets
   SHOULD be sent in AdminDown state for a period equal
   to (bfd.DesiredMinTxInterval * bfd.DetectMult) in order to ensure
   that the remote system is aware of the state change.

However a packet is never sent at  but also is based on the peers
RxInterval and we should not voilate the same. So BFD packets should
be sent "at least" till bfdSessNegotiatedInterval * bfdDetectMult and
can be sent for more. Note this interval can be bigger than the
interval you have specified in your document.

6. Section 3.4.2 should be clarified with respect to the slow timer
and fast timer, as that is how BFD sessions are currently controlled.
Also this section seems to change the BFD behavior but does not
clarify the same. Should the "Required Min RX Interval" be a big value
greater than the peer "esired Min TX Interval field"? If so an
explicit statement for the same needs to be added.

7.  Section 3.4.2 should come before 3.4.1.

Thanks again,
Vishwas

On Fri, Apr 9, 2010 at 1:47 AM, Loa Andersson <[email-masked]> wrote:
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>