Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

[Nobo Akiya <[e-mail]>]

Hi Greg,

Snipping out ones concluded (thanks for addressing them!).


> 4. Section 2.2.4
>
> There needs to be some synchronicity between AuthType/AuthKeyID to
> specified in "this" MPLS echo request message and AuthType/AuthKeyID being
> used by BFD control packets. For example:
>
> - If BFD control packets using "new" auth is received by the egress LSR
> before MPLS echo request with new "auth" is received, all BFD control
> packets using "new" auth will be dropped.
> - To take that a step further, if BFD control packets using "new" auth is
> received by the egress LSR before "this" MPLS echo request is received by
> the egress LSR and corresponding BFD session is updated to point to the
> "new" auth , all BFD control packets using "new" auth will be dropped.
> - If BFD control packets using "new" auth is only sent X time after
> sending the MPLS echo request with new "auth", then it is not guaranteed
> that the egress LSR will still be accepting BFD control packets with "old"
> auth for X amount of time.
> - And of course there's the error case of the egress LSR not being able to
> support the specified the "new" auth specified in received MPLS echo
> request, but the ingress LSR starts using the "new" auth before it receives
> back NOSUP from the egress LSR via MPLS echo reply.
>
> I suspect if sufficient details are not defined, we would likely run into
> some inter-op issues with this aspect.
>
> GIM>> I agree, more details should be provided. How about a new paragraph
> added to the section:
>    If BFD Authentication sub-TLV used for a BFD session in Up state then
>    the Sender of the MPLS LSP Echo Request SHOULD ensure that old and
>    new modes of authentication, i.e. combination of Auth.Type and Auth.
>    Key ID, used to send and receive BFD control packets until the
>    Sender can confirm that its peer had switched to the new
>    authentication.
>
>
IMO, I think there are couple of critical aspects which have to be
described.

1. Sender:
  a. Sender of BFD authentication change via MPLS echo request must not
start using the new authentication type/key until it receives back the
acknowledgement via MPLS echo reply.
  b. BFD authentication must change to the new authentication type/key
within a reasonable time after receiving back acknowledgement via MPLS echo
reply.

2. Receiver:
  a. Receiver of BFD authentication change in MPLS echo request must setup
the BFD receive path to accept both old & new authentication type/key for
the session before sending back the acknowledgement via MPLS echo reply.
  b. Old authentication type/key can get unassociated from the session once
the BFD session starts receiving the new authentication type/key.

Still there is one gotcha, which is that MPLS echo reply is unreliable
(i.e., typically an IP routed UDP packet). So there is a chance that MPLS
echo reply can get lost in transit. In addition, we need the receiver to
setup the SW/HW path (in step 2a above). That means the receiver may not be
able to send MPLS echo reply immediate (i.e., ping times out). To protect
from these, we probably want the sender to resent the BFD authentication
change in MPLS echo request if corresponding MPLS echo reply is not
received back.

Note, don't take above texts as is ... sort of wrote this email in a hurry.

Thanks!

-Nobo