Re: WGLC comments on bfd-mpls-05

[Rahul Aggarwal <[e-mail]>]

Hi Carlos,

<snipped>

> >
> >> If so, could the Security Considerations mention
> >> that the GTSM is not in effect in that direction,
> >> and with a routed
> >> multi-hop reply? Or should it be set to 255 and GTSM-checked on receipt?
> >> And in the egress -> ingress direction, should the TTL be set to 255
> >> (and checked for GTSM if the dest port if 3784, but not if the dest port
> >> is 4784)?
> >>
> >
> > The revised text will make it clear that for a routed reply
> > [BFD-MHOP] applies and otherwise [BFD-IP] applies. I don't think
> > there is any need to state the above here.
>
> Thanks. Would this apply only to encapsulation (since the text is within
> the Encapsulation section), or also to the GTSM procedures from
> [BFD-IP]? Could that be clarified as well, since it might not be
> directly apparent?
>

I will clarify this.

<snipped>

> >>
> >>     On receipt of the LSP-Ping echo request message, the egress LSR MUST
> >>     send a BFD control packet to the ingress LSR.  This BFD control
> >>     packet MUST set the Your Discriminator field to the discriminator
> >>     received from the ingress LSR in the LSP-Ping echo request message.
> >>
> >> I think this should additionally require successful FEC Validation
> >> ("Validate FEC Stack" flag in the MPLS echo request) before sending a
> >> BFD control packet back, or at least a successful (return-code 3) label
> >> operation check on receipt of the MPLS Echo request.
> >>
> >
> > This is normal LSP-Ping procedure.
>
> The normal LSP-Ping procedure generates an LSP-Ping reply with a result
> code that could differ from "AOK", and could for example be "Replying
> router has no mapping for the FEC at stack-depth <RSC>" or "No label
> entry at stack-depth <RSC>"; in these cases, in the new procedures, I
> think that the egress LSR should not send a BFD control packet (as there
> is a FEC<->Label mismatch detected, and the feature of using LSP-Ping
> with BFD so that "the presence of the FEC in the echo request message
> makes is possible to verify the control plane against the data plane at
> the egress LSR" would become a NOOP). Shouldn't the BFD session be
> bootstrapped only after a successful control-plane checking (and ideally
> including FEC Validation)?
>

I see there is value in clarifying this. Will do.

<snipped>

> >
> > How about inserting the following text to clarify this:
>
> I think this clarifies, with two small comments inline, thanks:
>
> >
> > "To enable fault detection procedures specified in this document, for a
> > particular MPLS LSP, this document requires the ingress and
> > egress LSRs to be configured. This includes configuration for supporting
> > BFD and LSP-Ping as specified in this document. It also includes
> > configuration that enables to the ingress LSR to determine the
>                 ^
>                 or signaling
>

The whole point is that this document does not specify any signaling to
discover the ingress/egress capabilities. It relies on configuration.

> > method used by the egress LSR to identify OAM packets e.g. whether the TTL
> > of the innermost MPLS label needs to be set to 1 to enable the egress LSR
> > to identify the OAM packet. This applies to fault detection for MPLS PWs
> > as well.
>
> "For fault detection for MPLS PWs, this document also assume that a PW
> control channel (e.g., a PW-ACH) and support for LSP-Ping are provided
> prior to initializing the procedures specified in this document, as
> specified in [RFC5085]. "
>
> or something along those lines.
>

I don't think that makes sense as this document relies on configuration.
Further there is no point in signaling LSP-Ping capability if BFD
capability cannot be signaled.

I fail to see why it is not enough to spell out that this document
requires configuration. It doesn't preclude capability signaling to be
added by another document.

> > Extending [RFC5085] procedures to signal BFD capability
> > between PW endpoints is outside the scope of this document."
> >
>
> Should this pointer to [RFC5085] be normative, and the one to
> pwe3-vccv-bfd in "The use of BFD for PWs is further described in [VCCV]
> and [OAM-MAP]." be informative?
>

Both should be informative pointers.

rahul