IETF Logo Mail Archive

Re: [Teas] <draft-ietf-teas-p2mp-loose-path-reopt-05>: Review

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Mon, 03 October 2016 12:45 UTC

Return-Path: <rgandhi@cisco.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF2112B19B; Mon, 3 Oct 2016 05:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.516
X-Spam-Level:
X-Spam-Status: No, score=-17.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXn2kpXwCSJz; Mon, 3 Oct 2016 05:45:27 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F390F12B08D; Mon, 3 Oct 2016 05:45:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10628; q=dns/txt; s=iport; t=1475498724; x=1476708324; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H1CTrdr0VnWdiCYqf6o4VtQpC60Q5HTLcSRfbixaFmA=; b=dF0s2Q/qDgKjYaJDV/utuDhwS1L3pybKYJCnY/SH/c4gf7NCTMaX93zm VMcIhtx+fupsmHF46Smai9OR5YMb6lDUt7PQGPxKJhPti9b1eTBtvPxnm btK+YOOXpb5xgvJvXnCjfBguKjei2KHGxfSlZvMvn1RwPWa5hXtaNifcE o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CGAQC7UfJX/49dJa1dGgEBAQECAQEBAQgBAQEBgwc2AQEBAQEegVMHjSuWf4dYhzmFEoIGhh4CHIFKOBQBAgEBAQEBAQFeJ4RhAQEBBCNWEAIBCBEDAQIoAwICAh8RFAkIAgQOBYgzAxevIoh1DYNOAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY4gX2CWIJHggQZgmQrgi8FlCCFIzUBjHCDAIFuhGaJHocLgVKEEYN9AR42gyAcgVByhlWBAAEBAQ
X-IronPort-AV: E=Sophos;i="5.31,289,1473120000"; d="scan'208,217";a="153786530"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2016 12:45:23 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u93CjN88001256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Oct 2016 12:45:23 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Oct 2016 07:45:23 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Mon, 3 Oct 2016 07:45:22 -0500
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Thread-Topic: <draft-ietf-teas-p2mp-loose-path-reopt-05>: Review
Thread-Index: AQHR2g+0x4A3hIHpuEa2fdFFsAptzqBpw+QAgCwlsQCAAVsRAA==
Date: Mon, 03 Oct 2016 12:45:22 +0000
Message-ID: <F4F7EF2E-A4A7-4E2B-8A4E-89034E93984D@cisco.com>
References: <CA+YzgTvG4_8yVrG7_OVqd-iYCnAnNUJcMOVN6As7riYt+ZrPxw@mail.gmail.com> <D3F19E06.A62D7%rgandhi@cisco.com> <CA+YzgTsnjvd1L8BzBvQq-q_iCH6f_UUK_sbfN0jszvaxWMcZZw@mail.gmail.com>
In-Reply-To: <CA+YzgTsnjvd1L8BzBvQq-q_iCH6f_UUK_sbfN0jszvaxWMcZZw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.249.43]
Content-Type: multipart/alternative; boundary="_000_F4F7EF2EA4A74E2B8A4E89034E93984Dciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/_e_gD2emNOYCYe8sDdiigZLbewk>
Cc: "draft-ietf-teas-p2mp-loose-path-reopt@ietf.org" <draft-ietf-teas-p2mp-loose-path-reopt@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Subject: Re: [Teas] <draft-ietf-teas-p2mp-loose-path-reopt-05>: Review
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2016 12:45:29 -0000

Hi Pavan,

Thank you for the review comments. Please see inline..<RG> ..

From: Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>
Date: Sunday, October 2, 2016 at 8:03 AM
To: RAKESH GANDHI <rgandhi@cisco.com<mailto:rgandhi@cisco.com>>
Cc: "draft-ietf-teas-p2mp-loose-path-reopt@ietf.org<mailto:draft-ietf-teas-p2mp-loose-path-reopt@ietf.org>" <draft-ietf-teas-p2mp-loose-path-reopt@ietf.org<mailto:draft-ietf-teas-p2mp-loose-path-reopt@ietf.org>>, "teas@ietf.org<mailto:teas@ietf.org>" <teas@ietf.org<mailto:teas@ietf.org>>
Subject: Re: <draft-ietf-teas-p2mp-loose-path-reopt-05>: Review

Rakesh, Hi!

Thanks for accommodating and addressing all suggestions/comments. I'm satisfied with the latest version and I agree that it is ready to be taken to the next step.

<RG> Great, thanks.


Couple of questions on the following change:


Comment: What happens if all fragments don’t show up (lost messages) at a given recipient node? Can you add some text discussing what needs to be done in that case.


*<end>*
<RG> Added following text:

   If a mid-point LSR does not receive all fragments of the
   Path message (for example, when fragments are lost), it SHOULD
   trigger re-evaluation of all S2L sub-LSPs of the P2MP-TE LSP
   transiting on the node.


   If an ingress node does not receive all
   fragments of the PathErr message (for example, when fragments are
   lost), it SHOULD trigger re-optimization of all S2L sub-LSPs of the
   P2MP-TE LSP transiting on the mid-point node that had sent the
   PathErr message.


When should a recipient node give up on waiting for more fragments? Use a configurable timer? A statement or two clarifying this in the draft would be useful.

<RG> Yes, using a configurable timer.  Sure, we can add text it in the next update.

If I understood the above text correctly, what the draft is saying is the following:
"If all the fragments are not received within a stipulated amount of time, the recipient node SHOULD behave the same way as it would when there are no fragments". Is this interpretation correct?

<RG> A node should receive at least one fragmented packet to trigger the above logic and should behave as if there were no fragmented message received for building the S2L list.

Thanks,
Rakesh


Regards,
-Pavan

v2.23.0 | Report a Bug | By Email