Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

John E Drake <jdrake@juniper.net> Fri, 17 August 2012 21:22 UTC

Return-Path: <jdrake@juniper.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84111E80F0 for <ccamp@ietfa.amsl.com>; Fri, 17 Aug 2012 14:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level:
X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-xV8ZVlkat8 for <ccamp@ietfa.amsl.com>; Fri, 17 Aug 2012 14:22:15 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2571411E80D1 for <ccamp@ietf.org>; Fri, 17 Aug 2012 14:22:15 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUC62BHfcsdPrB4L0O1BFZIqsyGaOcvk/@postini.com; Fri, 17 Aug 2012 14:22:15 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 17 Aug 2012 14:19:34 -0700
From: John E Drake <jdrake@juniper.net>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, Greg Mirsky <gregimirsky@gmail.com>, Francesco Fondelli <francesco.fondelli@gmail.com>
Date: Fri, 17 Aug 2012 14:19:32 -0700
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac18rlwA4D2YlfZKRGCBpFI+2JZEwgABuVOAAAA1SUAAAN63wAAAvlnAAAAigwA=
Message-ID: <5E893DB832F57341992548CDBB333163A631A84EF3@EMBX01-HQ.jnpr.net>
References: <20120815145324.17677.46437.idtracker@ietfa.amsl.com> <B7D2A316AA32B6469D9670B6A81B7C2406D3EF@xmb-aln-x07.cisco.com> <502D5125.6000105@labn.net> <B7D2A316AA32B6469D9670B6A81B7C2406D556@xmb-aln-x07.cisco.com> <502D61B8.5050106@labn.net> <5E893DB832F57341992548CDBB333163A631A84710@EMBX01-HQ.jnpr.net> <502D6F4D.7020707@labn.net> <B7D2A316AA32B6469D9670B6A81B7C2406D6CC@xmb-aln-x07.cisco.com> <CABP12JzD3yn2k-fDm02-mWs39nFMdGwe5xqmJUJckQqrShLRRQ@mail.gmail.com> <CA+RyBmX+2OmDdp94GMdSXGRefJwxB6d=8Xxs0PvH_vow0Jk2Mw@mail.gmail.com> <5E893DB832F57341992548CDBB333163A631A84E31@EMBX01-HQ.jnpr.net> <FE60A4E52763E84B935532D7D9294FF139268CBFA6@EUSAACMS0715.eamcs.ericsson.se> <5E893DB832F57341992548CDBB333163A631A84E97@EMBX01-HQ.jnpr.net> <FE60A4E52763E84B935532D7D9294FF139268CC000@EUSAACMS0715.eamcs.ericsson.se>
In-Reply-To: <FE60A4E52763E84B935532D7D9294FF139268CC000@EUSAACMS0715.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A631A84EF3EMBX01HQjnprn_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2012 21:22:20 -0000

Greg,

For both modes there is bidirectional flow of control packets.  For Independent mode the CC/CV packets flow in only one direction.

There never was a coupling between modes and associated/co-routed and if you can point me to any text that says the contrary I would appreciate it as a bis to remove that text would be required.

Thanks,

John

Sent from my iPhone

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, 2012 2:12 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi John,
in independent mode CC/CV control messages been sent only in one direction. Thus there are two CC/CV sessions - one for each independently monitored direction. That, AFAIK, was intentional.

    Regards,
        Greg

________________________________
From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Greg,

That certainly wasn't the intent.  With a bidirectional LSP of either type you have one forward and one return path and BFD does not care whether they are congruent.

Thanks,

John

Sent from my iPhone

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi John,
I think that bi-directional associated p2p LSP, regardless of how many common LSRs forward and reverse directions have, implies use of independent mode of RFC 6428, then there will be two sessions to monitor each direction independently. Coordinated mode of RFC 6428, in my understanding, applies to bidirectional co-routed p2p LSP.

    Regards,
        Greg

________________________________
From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] On Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19 PM
To: Greg Mirsky; Francesco Fondelli
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Greg,

According to RFC 6428 the is one CC/CV/RDI session irregardless of whether the bi-directional packet LSP is co-routed or associated.

Thanks,

John

Sent from my iPhone

From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27 PM
To: Francesco Fondelli
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi Francesco,
"from a data-plane view point b) and c2) are the same thing"
I think that given that c) is associated bi-directional LSP that implies independent OAM and protection for each direction, b) and c2) are not the same in the data plane view. E.g., there will be single CC/CV/RDI session for b) while c2) will have two sessions. And if linear protection requested, b) will be protected by single bi-directional LSP, but c2) - by two unidirectional LSPs.

Regards,
Greg
On Fri, Aug 17, 2012 at 1:48 AM, Francesco Fondelli <francesco.fondelli@gmail.com<mailto:francesco.fondelli@gmail.com>> wrote:
Hi All,

I think I'm lost, please help.

Rakesh is talking about "co-routed associated bidirectional
LSP"... for the sake of clarity, let me try to categorize
LSPs from a control plane view point:

  a) Point-to-point unidirectional
  b) Point-to-point co-routed bidirectional
  c) Point-to-point associated bidirectional
   c1) fwd and rev LSP follow different paths
   c2) fwd and rev LSP follow same path
  d) Point-to-multipoint unidirectional
  e) Multipoint-to-point unidirectional

Is section 3.2.5 (Signaling of Co-routed LSPs) of
mpls-tp-rsvpte-ext-associated-lsp about b) or it is about c2)?

In my opinion:

- b) should be signaled with 3473
- c) are addressed by this I-D (mpls-tp-rsvpte-ext-associated-lsp)

Am I missing something?

thank you
ciao
fra

PS
from a data-plane view point b) and c2) are the same thing.

On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi)
<rgandhi@cisco.com<mailto:rgandhi@cisco.com>> wrote:
> Hi Lou,
>
> Thanks for initiating discussions on the changes in the draft.
>
> Agree with you here, if we/WG do not agree on the "co-routed associated bidirectional LSP" part, we are ok to remove it from this draft and can always submit a new draft just for that. We respect your/WG decision.
>
> Thanks,
> Rakesh
>
>
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net<mailto:lberger@labn.net>]
> Sent: Thursday, August 16, 2012 6:08 PM
> To: John E Drake
> Cc: Rakesh Gandhi (rgandhi); ccamp@ietf.org<mailto:ccamp@ietf.org>
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>
> John,
>         While strictly speaking WG drafts should only reflect current WG consensus, and it is the WG draft editor's job to ensure this, in practice authors/editors are given a lot of latitude in timing / ordering in introduction to changes.  I personally think this is a practical way of keeping the process moving.  Also if the WG disagrees with a change, it can always be backed out.
>
> So, yes, the WG could do exactly as you say if it comes to it.  (The chairs can even appoint different editor if needed, e.g., to make this
> happen.)  While I'm not happy with how this revision came about, as I covered in earlier mail, my feeling is to let the discussion take place on the list (and at the next IETF, if needed) and then have the draft updated to reflect the WG discussion/consensus.
>
> Lou
>
> On 8/16/2012 5:35 PM, John E Drake wrote:
>> Lou,
>>
>> Since the WG did not agree to this changes, let alone discuss them,
>> would it be possible to simply rollback these changes and ask the
>> authors to write a draft addressing the topics you list in your email,
>> below?
>>
>> Thanks,
>>
>> John
>>
>> Sent from my iPhone
>>
>>
>>> -----Original Message-----
>>> From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>] On
>>> Behalf Of Lou Berger
>>> Sent: Thursday, August 16, 2012 2:10 PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> associated-lsp-04.txt
>>>
>>> Rakesh,
>>>      Such major changes (in scope and functionality) to WG drafts are
>>> usually discussed with the WG prior to the authors/editors just
>>> publishing the changes.  But, this is a judgment call by the document
>>> editors in how, quoting rfc2418, they "ensur[e] that the contents of
>>> the document accurately reflect the decisions that have been made by
>>> the working group."
>>>
>>> So let's jump into discussing the changes.
>>>
>>> As I see it this draft introduces several major functional changes
>>> that have not been discussed by the WG.  Correct me if I get them
>>> wrong, but I believe they include:
>>> 1) Introduction of a second method for signaling Co-routed LSPs
>>> 2) Support for FRR bypass tunnels for piggybacked on the TP
>>> bidirectional LSP mechanisms.
>>>
>>>    There are also other changes, but I'll defer discussing them
>>>    until the discussion on the above is concluded.
>>>
>>> Is this correct?
>>>
>>> Assuming yes, I have questions about both rational and specific
>>> mechanisms.  For now let's look at the former, so please:
>>>
>>> A) Articulate the issues/limitations with using the RFC3473 defined
>>> mechanisms for (co-routed) bidirectional LSPs that you'd like to see
>>> addressed.
>>>
>>> B.1) Articulate the FRR/GMPLS-related issue you'd like to address?
>>>
>>> B.2) Articulate why this issue should be solved in a TP-specific and
>>> not GMPLS generic fashion?
>>>
>>> Thanks,
>>> Lou
>>>
>>> On 8/16/2012 4:26 PM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou,
>>>>
>>>> Yes.
>>>>
>>>> Please advise if you think detailed email is required.
>>>> We believe latest draft summarizes the changes well and we could
>>> start review/discussions from there.
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net<mailto:lberger@labn.net>]
>>>> Sent: Thursday, August 16, 2012 4:00 PM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>; zhang.fei3@zte.com.cn<mailto:zhang.fei3@zte.com.cn>
>>>> Subject: Re: [CCAMP] I-D Action:
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> Rakesh,
>>>>     Is this the start of the thread that I requested in
>>>> http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html
>>>>
>>>> In particular, is it the response to:
>>>>> I'd like to ask that someone (Rakesh, Fei, etc.) review each of the
>>>>> proposed change and the rational for each change (in one or in
>>>>> separate e-mails). The WG discussion can then really begin on the
>>>>> proposed changes. (Which are quite substantial both in scope and
>>>>> implication.)
>>>>
>>>> Lou
>>>>
>>>> On 8/16/2012 3:19 PM, Rakesh Gandhi (rgandhi) wrote:
>>>>> Hi All,
>>>>>
>>>>> We have uploaded a new version of this draft with following changes:
>>>>
>>>> 1.  Added a section on Signaling of Co-routed LSPs
>>>>
>>>> 2.  Added clarification on Signaling of Associated Bidirectional
>>>> Protection LSPs
>>>>
>>>> 3.  Added a section on Signaling of Auto-tunnel Mesh-group LSPs
>>>>
>>>> 4.   Added clarification on Signaling of Inter-domain Associated
>>> Bidirectional LSPs
>>>>
>>>> 5.  The Extended ASSOCIATION object format with Association Type
>>> "Associated Bidirectional LSP". Clarified on how to populate
>>> different fields in this object.
>>>>
>>>>
>>>>> We believe that some of these changes were necessary to avoid the
>>> interoperability issues due to potentially different interpretations.
>>>>>
>>>>> Your review comments are welcome.
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>> -----Original Message-----
>>>>> From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>] On
>>>>> Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
>>>>> Sent: Wednesday, August 15, 2012 10:53 AM
>>>>> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
>>>>> Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
>>>>> Subject: [CCAMP] I-D Action:
>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>>>  This draft is a work item of the Common Control and Measurement
>>> Plane Working Group of the IETF.
>>>>>
>>>>>    Title           : RSVP-TE Extensions for Associated Bidirectional
>>> LSPs
>>>>>    Author(s)       : Fei Zhang
>>>>>                           Ruiquan Jing
>>>>>                           Rakesh Gandhi
>>>>>    Filename        : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>>> lsp-04.txt
>>>>>    Pages           : 17
>>>>>    Date            : 2012-08-15
>>>>>
>>>>> Abstract:
>>>>>    The MPLS Transport Profile (MPLS-TP) requirements document
>>> [RFC5654],
>>>>>    describes that MPLS-TP MUST support associated bidirectional
>>> point-
>>>>>    to-point LSPs.
>>>>>
>>>>>    This document provides a method to bind two unidirectional Label
>>>>>    Switched Paths (LSPs) into an associated bidirectional LSP.  The
>>>>>    association is achieved by defining the new Association Type in
>>> the
>>>>>    Extended ASSOCIATION object.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>>>> a
>>>>> ssociated-lsp
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>>> associ
>>>>> a
>>>>> ted-lsp-04
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-
>>> ext-
>>>>> a
>>>>> ssociated-lsp-04
>>>>>
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org<mailto:CCAMP@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org<mailto:CCAMP@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org<mailto:CCAMP@ietf.org>
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org<mailto:CCAMP@ietf.org>
https://www.ietf.org/mailman/listinfo/ccamp