Re: [mpls-tp] Demultiplexing to BFD sessions

Apratim Mukherjee <AMukherjee@ixiacom.com> Thu, 01 July 2010 09:17 UTC

Return-Path: <AMukherjee@ixiacom.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9320D3A68CB; Thu, 1 Jul 2010 02:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.546
X-Spam-Level:
X-Spam-Status: No, score=0.546 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908]
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 ZZaUtCeYmhIV; Thu, 1 Jul 2010 02:17:39 -0700 (PDT)
Received: from ixqw-mail-out.ixiacom.com (ixqw-mail-out.ixiacom.com [66.77.12.12]) by core3.amsl.com (Postfix) with ESMTP id 8CCB53A68AA; Thu, 1 Jul 2010 02:17:39 -0700 (PDT)
Received: from ixcaexch07.ixiacom.com ([fe80:0000:0000:0000:e021:fcf5:238.143.231.20]) by ixqw-hc1.ixiacom.com ([10.210.5.15]) with mapi; Thu, 1 Jul 2010 02:17:51 -0700
From: Apratim Mukherjee <AMukherjee@ixiacom.com>
To: Mukund Mani <mukund.mani@gmail.com>
Date: Thu, 1 Jul 2010 02:17:47 -0700
Thread-Topic: [mpls-tp] Demultiplexing to BFD sessions
Thread-Index: AcsY8zaS8a5XAzHlQKOYYm1WcK9aqgABw9/gAADw/pA=
Message-ID: <716209EC190CA740BA799AC4ACCBFB5D180C4B82B7@IXCAEXCH07.ixiacom.com>
References: <AANLkTikZurkVBrPNBjL-v7zdZ9dTLUBDuBnNDPsCrnJf@mail.gmail.com> <OF7E03B6CE.B5C7073D-ON48257750.000D15FC-48257750.000D4123@zte.com.cn> <716209EC190CA740BA799AC4ACCBFB5D180C3C7126@IXCAEXCH07.ixiacom.com> <AANLkTikdY-qChtT8-po0L6eCjW6qWQ2LzqMhG1eysmvP@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD6940E808F75@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD518156D6E3@EUSAACMS0703.eamcs.ericsson.se> <AANLkTinSalhepoG_AuvNLbVWHTgkF01etfLzRXWxpr5c@mail.gmail.com> <60C093A41B5E45409A19D42CF7786DFD518156D754@EUSAACMS0703.eamcs.ericsson.se> <AANLkTinzsvrfAbBrkLObJmXd4fNvk8CyOKokNE16UGpT@mail.gmail.com> <716209EC190CA740BA799AC4ACCBFB5D180C4B7A71@IXCAEXCH07.ixiacom.com> <2C2F1EBA8050E74EA81502D5740B4BD6940E8090F8@SJEXCHCCR02.corp.ad.broadcom.com> <716209EC190CA740BA799AC4ACCBFB5D180C4B81DA@IXCAEXCH07.ixiacom.com> <AANLkTilDZFkqfgnP5zi8mb5LKlOrGe9cx-B_cQ_Mky-Z@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "mpls-tp-bounces@ietf.org" <mpls-tp-bounces@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 09:17:40 -0000

Hi Mukund 

Comments inline.

Regards,
Apratim
=====================================================================================================
From: Mukund Mani [mailto:mukund.mani@gmail.com] 
Sent: Thursday, July 01, 2010 1:29 PM
To: Apratim Mukherjee
Cc: Shahram Davari; Greg Mirsky; David Allan I; xiao.min2@zte.com.cn; mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Hi Apratim
For your first point I agree with you and had raised this some time back. I was under the impressions that things would be clear with the next version of the CC/CV draft.
But I would like to mention here w.r.t the scenario of independent sessions. As per CC/CV draft, Your Discriminator will be zero when not known else it can reflect the 
My Discriminator vlaue. 
So the fast packets for BFD1 from Node A to Node B, can have both both the Your and My discriminators present. So when I say that label alone is not enough to demultiplex, that is because (as you mention) both the fast and slow packets would arrive with the same label. 
Thus we anyway need to refer to the Your discriminator value also to find the correct session context . 

[Apratim Mukherjee] This is where my concern was . If we choose to do it this way , discriminators need to be known ( via configuration/lsp ping extension exchange of discriminators) before starting the BFD sessions.
So in case of independent sessions label and discriminator might both be required
to find the session context.

For the MEP id, IMHO even for the independent session case, considering associated bi-directional LSP,
we would have a Source and a Sink MEP for each direction. The BFD session initiator of each independent session (at either end) will be identified IMO as mentioned below in 
my previous mail..

[Apratim Mukherjee] Probably you are correct i.e. “Unique MEP-ID of source of the BFD packet” is indeed different for each of the two packets coming from same node using same label stack. Greg also seems to be indicating the same thing. In that case for BFD-CC-CV in independent mode ( and also for the fate sharing mode)  ,this is indeed a correct solution on how to locate BFD session correctly from the two packets received for different BFD sessions with same label and not using the Discriminator ( esp. if that is 0 ) . However , this was not clear to me from my understanding of draft-swallow-mpls-tp-identifiers-02 . I was under the impression that it is designed for bidirectional GRSVP-TE session ( which could instead also be statically configured ) which would make Node ID / Tunnel ID and Lsp Id same for the MEP-ID in both the BFD packets from the same node  unless Rx and Tx directions have different LSP IDs or an additional identifier is added to MEP Id to indicate Tx/Rx direction.


With Regards

Mukund
On Thu, Jul 1, 2010 at 12:52 PM, Apratim Mukherjee <AMukherjee@ixiacom.com> wrote:
Hi Mukund /Shahram 
 
I think single BFD bidirectional session and unique MEP Ids are all correct arguments for the normal use-case.
 
I have attempted to raise the point only in context  of ‘independent’ BFD sessions over a bidirectional LSP ( for 1+1 uni-directional switchover case).
In this case , my understanding is that there are 2 BFD sessions running independent of 
 
each other with each BFD session protecting one direction of the LSP. ( Section 3.5 of draft-ietf-mpls-tp-cc-cv-rdi-00 : “A single bi-directional BFD session is used for fate sharing operation. Two independent BFD sessions are used for independent operation.”
 
Node A                                                                         Node B 
OutLabel = L11 → BFD1 fast packets   + BFD2 packets during state change →      InLabel = L11
InLabel  = L12 ← BFD1 packets during state change + BFD2 fast packets   →      OutLabel = L12
 
So if L11 side is down , in steady state BFD1 is in Down State on Node B  but BFD2 is in Up State on Node B .
 
In steady state my assumption is that Discriminators will be different from same node for the two sessions.
 
My assumption here is that when Node B is sending BFD1 and BFD2 packets both using OutLabel = L12 AND if Your Discriminator is 0 in the packet,
Node A has no way to distinguish between packets for BFD1 or BFD2 . The only difference is really the Min Rx Interval in the packets . 
I assumed here that  even if MEP Id is included , the MEP Id as defined today would be Global Id + Node B Id + TunnelId + Lsp id in both the packets I.e for Node B Rx and Tx links have the same Lsp Id  unless I have got the definition for MEP Id wrong.
 
P.S : I think I am missing something here regarding the MEP IDs from Greg’s mail snippet
Per Greg “I think "independent" OAM uni-directional OAM session requires separate MEG and, consequently, MEP ID will be unique for each session, direction of the bi-directional LSP in your scenario. That is why I think that MEP ID TLV would not be the same as you've suggested.”
 
Per Mukund “IMHO the MEP id will be different.  Eg as far as the identification goes say the forward direction is from node A to node B, MEP for the forward path can be identified as A::Tnl X::LSP1 and the reverse path MEP can be identified as B::Tnl Y::LSP2.” → I think this is for bi-directional sessions but not true for the independent mode we are discussing here .
 
 
 
Regards,
Apratim