Re: WGLC comments on bfd-mpls-05

Carlos Pignataro <cpignata@cisco.com> Tue, 06 May 2008 18:51 UTC

Return-Path: <rtg-bfd-bounces@ietf.org>
X-Original-To: rtg-bfd-archive@megatron.ietf.org
Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CDB3A6C10; Tue, 6 May 2008 11:51:11 -0700 (PDT)
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B573A6890 for <rtg-bfd@core3.amsl.com>; Tue, 6 May 2008 11:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqEGV8htom37 for <rtg-bfd@core3.amsl.com>; Tue, 6 May 2008 11:51:04 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 312273A6C10 for <rtg-bfd@ietf.org>; Tue, 6 May 2008 11:51:04 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m46Ip1202869; Tue, 6 May 2008 14:51:01 -0400 (EDT)
Received: from [64.102.157.132] (dhcp-64-102-157-132.cisco.com [64.102.157.132]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m46Ipru06526; Tue, 6 May 2008 14:51:53 -0400 (EDT)
Message-ID: <4820A894.2040608@cisco.com>
Date: Tue, 06 May 2008 14:51:00 -0400
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Rahul Aggarwal <rahul@juniper.net>
Subject: Re: WGLC comments on bfd-mpls-05
References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net>
In-Reply-To: <20080505154957.M81069@sapphire.juniper.net>
X-Enigmail-Version: 0.95.6
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ross Callon <rcallon@juniper.net>, rtg-bfd@ietf.org, dward@cisco.com
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

Hi Rahul,

Thanks, please see inline.

On 5/5/2008 7:54 PM, Rahul Aggarwal said the following:
> Hi Carlos,
> 
> <snipped>
> 
>>>> There may also be multiple ECMPs for other FECs, like VPNv4/VPNv6
>>>> prefixes. Does this SHOULD apply to those as well?
>>> No. As in those cases the ingress LSR knows the multiple paths and there
>>> is no need to use the LSP-traceroute mechanism.
>>>
>>>> For other FECs, there
>>>> wouldn't be ECMPs (e.g., PWs RFC 4928), should that be explicitly mentioned?
>>>>
>>> No. The above text applies only to the LDP ECMP case.
>> I meant for VPNv4 stacked over LDP FECs. Testing a VPNv4 FEC may result
>> in multipaths from the underlying LDP ECMPs. Does the SHOULD apply in
>> that case as well?
>>
> 
> No.
> 
>>>> ---
>>>>
>>>> 5. Initialization and Demultiplexing
>>>>
>>>>
>>>>     A BFD session may be established for a FEC associated with a MPLS
>>>>     LSP. As desribed above in the case of PHP and next-hop label
>>>>     allocation the BFD control packet received by the egress LSR does not
>>>>     contain sufficient information to associate it with a BFD session.
>>>>     Hence the demultiplexing MUST be done using the remote discriminator
>>>>     field in the received BFD control packet. The exchange of BFD
>>>>     discriminators for this purpose is described in the next section.
>>>>
>>>> 6. Session Establishment
>>>>
>>>>     To establish a BFD session a LSP-Ping echo
>>>>     request message MUST carry the local discriminator assigned by the
>>>>     ingress LSR for the BFD session. This MUST subsequently be used as
>>>>     the My Discriminator field in the BFD session packets sent by the
>>>>     ingress LSR.
>>>>
>>>> There seem to be other additional cases besides PHP where discriminators
>>>> need to be exchanged/boot-strapped (e.g., UHP and single label),
>>> UHP is a valid case and I will mention it.
>>>
>>>> but
>>>> situations where it's not needed (e.g., PWs). Should these cases be
>>>> enumerated/framed or clarified? Is this "MUST" (the first one in Section
>>>> 6) too strong considering cases where bootstrapping with LSP-Ping is not
>>>> needed (e.g., PWs) or should the MUST be conditioned to the cases where
>>>> is needed?
>>>>
>>> For consistant operation of the BFD MPLS state machine the procedures in
>>> this document require LSP-Ping bootstrapping to all types of LSPs.
>>> Hence the text should stay as is.
>> But this adds a dependency on LSP-Ping that is not "required". Section
>> 3.2 of the document lists three functions for which LSP-Ping is used,
>> that are not directly applicable to the PW case (a. and b. do not apply
>> to PW LSPs, and c. is optionally applicable, but orthogonal/not tied to
>> the BFD procedures).
>>
> 
> Section 3.2 states the following that applies to PWs:
> 
> "In addition to
>    this presence of the FEC in the echo request message makes it
>    possible to verify the control plane against the data plane at the
>    egress LSR."

Yes, but Section 3.1 says the following:

    In addition LSP-Ping also
    provides a mechanism for verifying the MPLS control plane against the
    data plane.
    [...]
    BFD cannot be used for verifying the MPLS control plane against the
    data plane.  However BFD can be used to detect a data plane failure
    in the forwarding path of a MPLS LSP.
    [...]
    LSP-Ping includes extensive control plane verification. BFD on the
    other hand was designed as a light-weight means of testing only the
    data plane. As a result, LSP-Ping is computationally more expensive
    than BFD for detecting MPLS LSP data plane faults. BFD is also more
    suitable for being implemented in hardware or firmware due to its
    fixed packet format. Thus the use of BFD for detecting MPLS LSP data
    plane faults has the following advantages:
    [...]
    There may be other potential cases where fast failure detection is
    desired for MPLS LSPs.

The control-plane verification is inherent to LSP-Ping, and orthogonal 
to running BFD over the PW. It's not an inherent dependency (running 
LSP-Ping independent of BFD seems to achieve the same).


> 
> 
>>>> ---
>>>>
>>>> 6. Session Establishment
>>>>
>>>>     On receipt of the LSP-Ping echo request message, the egress LSR MUST
>>>>     send a BFD control packet to the ingress LSR.
>>>> ...
>>>> 7. Encapsulation
>>>>
>>>>     BFD control packets sent by the egress LSR are UDP packets. The
>>>>     source IP address is a routable address of the replier; the source
>>>>     port is the well-known UDP port 3784.  The destination IP address and
>>>>     UDP port MUST be copied from the source IP address and UDP port of
>>>>     the control packet received from the ingress LSR.
>>>>
>>>> LSP-Ping (ingress->egress) is used to exchange the ingress My
>>>> Discriminator. And then a BFD Control packet (egress->ingress) is used
>>>> to exchange the egress My Discriminator. Section 6 says that the egress
>>>> replies with a BFD Control packet (before it has received a BFD Control
>>>> packet from ingress), and Section 7 says that the egress copies the dest
>>>> UDP port from the source's ingress.
>>>> Therefore it seems that the
>>>> destination UDP Port of the first BFD Control packet (from egress to
>>>> ingress) is unspecified, and could be anything in the [49152 .. 65535]
>>>> range since:
>>>>
>>>>     The BFD control packet sent by the ingress LSR MUST be a UDP packet
>>>>     with a well known destination port 3784 [BFD-IP] and a source port
>>>>     assigned by the sender as per the procedures in [BFD-IP].
>>>>
>>>> Should the egress use also 3784 as destination port in the first BFD
>>>> Control packet?
>>> Thanks for catching this bug. The egress should either use 3784 as the
>>> dest port if the return packet is being tunnelled. It should use 4784
>>> otherwise. I will clarify this.
>> Thanks. But in this case, if the packet is being tunneled, the BFD would
>> have both udp.src and udp.dst as 3784, right? And if not tunneled, the
>> pair 3794/4784, instead of using udp source from [49152 .. 65535].
>>
> 
> No. The modified text will say the following:
> 
> "The BFD control packet sent by the egress LSR MUST have a well known
> destination port 4784, if it is routed [BFD-MHOP], or it MUST have a
> well known destination port 3784 [BFD-IP] if it is encapsulated in a
> MPLS label stack. The source port MUST be assigned by the egress lSR
> as per the procedures in [BFD-IP]."
> 

Thanks. That clarifies.

Regarding IP addresses, that para would continue with something like 
this, right?

    The source IP address is a routable address of the replier.  The
    destination IP address MUST be copied from the source IP address of
    the LSP-Ping echo request message received from the ingress LSR.

Also, I just noticed that the regarding the TTL, the text says (does it 
apply to both directions since it's in a separate para?):

    The IP TTL MUST be set to 1.

Is this done intentionally to ensure intercepting the packet to the 
control plane in the ingress -> egress direction (even with the 
destination in 127/8)? 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)?

>>>
>>>> Should the port be also included in the LSP-Ping
>>>> message? Or should the UDP port be allowed to change in the first packet
>>>> from the ingress->egress?
>>>> If the egress uses 3784 as dest UDP port, these two requirements from
>>>> [BFD-IP] seem to end up contradicting on this case:
>>>>
>>>>     The same UDP
>>>>     source port number MUST be used for all BFD Control packets
>>>>     associated with a particular session.  The source port number SHOULD
>>>>     be unique among all BFD sessions on the system.
>>>>     ...
>>>>     but the number of distinct uses of
>>>>     the same UDP source port number SHOULD be minimize
>>>>
>>>> So that would seem to leave the other two options (send the UDP Port in
>>>> the LSP-Ping, or allow for the UDP Port to change during the handshake.
>>>>
>>> Specifying the dest port as 3784 or 4784 for the egress to ingress BFD
>>> packets addresses this.
>>  From ingress to egress, the spec says in Section 7:
>>
>>     The BFD control packet sent by the ingress LSR MUST be a UDP packet
>>     with a well known destination port 3784 [BFD-IP] and a source port
>>     assigned by the sender as per the procedures in [BFD-IP].
>>
> 
> This is correct.
> 
>> And from egress to ingress, the spec says in Section 7:
>>
>>     BFD control packets sent by the egress LSR are UDP packets. The
>>     source IP address is a routable address of the replier; the source
>>     port is the well-known UDP port 3784.
>>
>> If from egress -> ingress the dest port is 3784 or 4784, it could end up
>> with both fixed src and dst ports (in which it seems it does not address
>> the two requirements from [BFD-IP]). Or how would the flow be in this case?
>>
> 
> See above for the modified text. The intention was to use the source port
> as in [BFD-IP].
> 
>> Should the egress instead send his own MyDisc in an LSP-Ping echo reply,
>> and have the ingress send the first BFD Control message? Or the ingress
>> communicate also its source port in the LSP-Ping echo?
>>
>>>> ---
>>>>
>>>> 7. Encapsulation
>>>>
>>>>     For MPLS PWs, alternatively,
>>>>     the presence of a fault detection message may be indicated by setting
>>>>     a bit in the control word [VCCV].
>>>>
>>>> This procedure needs signaling or static configuration to create the
>>>> VCCV control channel before BFD packets could be exchanged over the
>>>> control channel (with the bit in the CW). Are more details needed?
>>> I will specify that the two ends in this case are assumed to be configured
>>> to use this control channel. And signaling this capability is outside the
>>> scope of this document.
>> That would address the CC Type, but not the CV Type.
>>
> 
> This draft applies to *only* BFD for MPLS LSPs. Hence the CV type
> discussion is simply not relevant.

Please see below.

> 
>>>> 11.2. Informative References
>>>>
>>>>       [VCCV]     T. Nadeau, C. Pignataro, R. Aggarwal,
>>>>                  "Pseudo Wire (PW) Virtual Circuit Connection Verification
>>>>                  ((VCCV)", draft-ietf-pwe3-vccv-13.txt
>>>>
>>>> This reference points to rev 13 of this document. In the subsequent
>>>> revision, this document was split into what resulted in RFC 5085 and the
>>>> ID draft-ietf-pwe3-vccv-bfd. It seems that some citations refer to the
>>>> former, while others to the latter, and they appear to be made in a
>>>> Normative fashion (e.g., because the VCCV control channel needs to exist
>>>> in order to send BFD packets over it).
>>>> However, given that PWs need an associated VCCV control channel, do not
>>>> need LSP-Ping boot-strapping (as can get the context from the PW label),
>>>> should this document point to draft-ietf-pwe3-vccv-bfd (that goes into
>>>> different BFD functional modes) for the PW case instead of also defining
>>>> it here, since it has a number of specific unique issues?
>>>>
>>> This document simply needs to point to RFC 5085 for the control word based
>>> control channel.
>> Yes, for the control channel, but it would still lack the connectivity
>> verification (CV) types.
>>
> 
> This draft specifies procedures for *only BFD*. Hence the entire
> CV type discussion is simply not relevant.
> 
>>> "The use of BFD for PWs is further described in [VCCV] and [OAM-MAP]."
>>>
>>> It should point to draft-ietf-pwe3-vccv-bfd in the above statement
>>> in section 3.1
>> I think there's one problem and two limitations with that approach. The
>> issue is that, for BFD to be run over the control-channel, it would need
>> to define the CV Type(s)/payload type(s) for BFD (as a normative
>> procedure).
> 
> As I said this draft specifies fully standalone procedures to run BFD over
> a MPLS LSP including PWs. For a bidrectional LSP both
> ends are supposed to be configured for BFD.
> 
> Signaling BFD as a CV type is certainly not required for the procedures in
> this draft.

If this specification makes use of the control channel from RFC5085 for 
PW LSPs, only fault detection message payload types that are signaled 
and agreed as CV types can run over the control channel, from RFC5085.

> 
>> The limitations are that, for the PW case there is no
>> requirement to use LSP-Ping to bootstrap the session (and can remove the
>> dependency on LSP-Ping for the PW case),
> 
> For the procedures in this draft bootstrapping using LSP-Ping is a MUST.
> As for reasons for using LSP-Ping for PWs in conjunction with BFD see
> section 3.2:
> 
> ""In addition to
>    this 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."
> 

Yes. Agreed.

Along these lines, the Session Establishment procedures in Section 6 say:

    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.

> 
>> and the other limitation is
>> regarding alternate encapsulations for BFD (PW-ACH mode, and functional
>> modes specified as different CV Types as well).
>>
> 
> The use of PW-ACH is spelled out in RFC5085. The use of other CV types is
> simply not relevant to this draft as it covers only BFD.

LSP-Ping over PW-ACH is defined in RFC5085, so the LSP-Ping CV Type is 
relevant for the PW case, or it could not bootstrap the session. From 
RFC5085, for other connectivity-verification/payload types (like BFD) 
over the PW-ACH, a CV Type is needed.

The procedures in this draft strictly seem to update these rules, with 
an implicit CV Type "negotiation"/agreement by means of sending (at the 
ingress LSR) and parsing/understanding (at the egress LSR) the BFD 
Discriminator TLV in the MPLS Echo request. There is the bootstrapping 
(and LSP-Ping as a CV Type over the PW-ACH should have been negotiated 
before this can happen for the PW case from RFC5085) as a "negotiation", 
so there wouldn't be unexpected CV Types/payloads received (if the BFD 
TLV is not supported it would result in "TLV not understood" since it's 
15). But I think this would need to be spelled out.

Thanks,

--Carlos.

> 
> rahul
> 
>> Thanks again,
>>
>> --Carlos.
>>
>>> rahul
>>>
>>>
>>>> Thanks,
>>>>
>>>> --
>>>> --Carlos Pignataro.
>>>> Escalation RTP - cisco Systems
>>>>
>>>>
>>>>
>>>>
>> --
>> --Carlos Pignataro.
>> Escalation RTP - cisco Systems
>>
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems