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

From: [email-masked]
Date: Wed, 15 Aug 2012 07:53:24 -0700

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-associated-lsp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 16 Aug 2012 19:19:00 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, August 15, 2012 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Abstract:

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Aug 2012 15:59:33 -0400

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 16 Aug 2012 20:26:45 +0000

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:[email-masked]] 
Sent: Thursday, August 16, 2012 4:00 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
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

Lou

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Aug 2012 17:10:16 -0400

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 16 Aug 2012 21:26:52 +0000

Hi Lou,

Thank you for your comments.

We had several email exchanges on the alias on "signaling of co-routed LSPs" before it was added in the draft. 

Regarding A)

I agree with you that GMPLS signaling can be used for co-routed LSPs and has many advantages.

Goal of the associated bidirectional LSPs is to tie the two independent LSPs together. These two LSPs may be non co-routed or co-routed. It is useful for an application to specify the node to request both LSPs go on the same path. Do you agree? 

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 5:10 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
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."

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.

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.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:
> Subject: Re: [CCAMP] I-D Action: 
>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>> a
>> ssociated-lsp
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ
>> a
>> ted-lsp-04
>>
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-
>> a
>> ssociated-lsp-04
>>
>>

---

From: John E Drake <[email-masked]>
Date: Thu, 16 Aug 2012 14:35:52 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lou Berger
> Sent: Thursday, August 16, 2012 2:10 PM
> 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."
> 
> > 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.
> >>

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Aug 2012 17:41:55 -0400

Rakesh,

On 8/16/2012 5:26 PM, Rakesh Gandhi (rgandhi) wrote:
> We had several email exchanges on the alias on "signaling of
> co-routed LSPs" before it was added in the draft.

I presume you're referring to your private e-mail exchange that was
forwarded to the list, mid-stream, under the subject "Re: [CCAMP]
Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03".

I addressed this in
http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html.  If
you disagree with that e-mail, please respond to it.

> Goal of the associated bidirectional LSPs is to tie the two
> independent LSPs together. These two LSPs may be non co-routed or
> co-routed. It is useful for an application to specify the node to
> request both LSPs go on the same path. Do you agree?

Not sure I understand your question.  Per RFC5654 and RFC6373 there is a
stated need for associated and co-routed MPLS TP transport paths.  As
discussed in RFC6373, RFC3473 already supports co-routed bidirectional
LSPs.  The draft we're discussing covers associated bidirectional.

Can you rephrase the issue/function that you believe is not addressed in
current signaling RFCs?

Lou

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 16 Aug 2012 21:59:41 +0000

Hi Lou,

Please see inline..<RG>..

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 5:42 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,

> LSPs" before it was added in the draft.

I presume you're referring to your private e-mail exchange that was forwarded to the list, mid-stream, under the subject "Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03".

I addressed this in
http://www.ietf.org/mail-archive/web/ccamp/current/msg13729.html.  If you disagree with that e-mail, please respond to it.

> request both LSPs go on the same path. Do you agree?

Not sure I understand your question.  Per RFC5654 and RFC6373 there is a stated need for associated and co-routed MPLS TP transport paths.  As discussed in RFC6373, RFC3473 already supports co-routed bidirectional LSPs.  The draft we're discussing covers associated bidirectional.

Can you rephrase the issue/function that you believe is not addressed in current signaling RFCs?

<RG> I understand what you are saying and do not see any issue there. But I am not looking at it from that view point. All we are saying is that when bidirectional LSPs are associated via signaling, they could take the same path and it can be provisioned to do so.  

Thanks,
Rakesh

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Aug 2012 18:08:13 -0400

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
> 
>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 16 Aug 2012 22:16:33 +0000

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:[email-masked]] 
Sent: Thursday, August 16, 2012 6:08 PM
To: John E Drake
Cc: Rakesh Gandhi (rgandhi); [email-masked]
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:
> authors to write a draft addressing the topics you list in your email, 
> below?
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
> 
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Lou Berger
>> 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:
>> "Associated Bidirectional LSP". Clarified on how to populate 
>> different fields in this object.
>>>
>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Aug 2012 18:17:17 -0400

Rakesh,
	See below.

On 8/16/2012 5:59 PM, Rakesh Gandhi (rgandhi) wrote:
> <RG> I understand what you are saying and do not see any issue there.
> But I am not looking at it from that view point.

Actually, I'm not making any statement on if there's an issue or not.
I'm asking you to state the issue or new function that you'd like
addressed by a new mechanism.  It's really simple, if there's no issue
or need for a new function, then there's no need to defined a new mechanism.

I'm guessing that you see an issue or limitation, and I'd genuinely like
to understand what it is.

> All we are saying is
> that when bidirectional LSPs are associated via signaling, they could
> take the same path and it can be provisioned to do so.

Well, this is already stated in RFC5654 (and referenced RFC6373).  If
that's it, we can easily close this topic.

Lou

>>>> Behalf Of [email-masked]

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 16 Aug 2012 22:24:36 +0000

Hi Lou.

Let me go through the references listed below and get back.

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 6:17 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,
	See below.

Actually, I'm not making any statement on if there's an issue or not.
I'm asking you to state the issue or new function that you'd like addressed by a new mechanism.  It's really simple, if there's no issue or need for a new function, then there's no need to defined a new mechanism.

I'm guessing that you see an issue or limitation, and I'd genuinely like to understand what it is.

> take the same path and it can be provisioned to do so.

Well, this is already stated in RFC5654 (and referenced RFC6373).  If that's it, we can easily close this topic.

Lou

>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ex
>>>> t
>>>> -
>>>> a
>>>> ssociated-lsp
>>>>
>>>> http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-asso
>>>> c
>>>> i
>>>> a
>>>> ted-lsp-04
>>>>
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ex
>>>> t
>>>> -
>>>> a
>>>> ssociated-lsp-04
>>>>
>>>>

---

From: [email-masked]
Date: Fri, 17 Aug 2012 08:55:47 +0800

Hi Lou, John

As an editor of this draft, be apologized that I am not familar with the 
WG consensus procedures and even do not read RFC2418. It is my fault and 
will not happen again.

Best regards

Fei

Lou Berger <[email-masked]> 
发件人:  [email-masked]
2012-08-17 06:08

收件人
John E Drake <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
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

Lou

On 8/16/2012 5:35 PM, John E Drake wrote:
>>>>             Title           : RSVP-TE Extensions for Associated 
Bidirectional
>> LSPs
>>>>             Filename        : 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-
>> lsp-04.txt

---

From: [email-masked]
Date: Fri, 17 Aug 2012 09:19:31 +0800

Lou

Regarding B.1 and B.2

2) Support for FRR bypass tunnels for piggybacked on the TP
bidirectional LSP mechanisms

I do not think we introduce the FRR bypass tunnels in this draft, which is 
used for local protection (RFC4090).

Do you see them in section 3.2.4 or section 3.2.6, I personally think they 
are GMPLS generic fashion and are totally informational.

If the descriptions mislead you, please give us some guidance and we are 
happy to revise them.

Best regards

Fei

2012-08-17 05:10

收件人
"Rakesh Gandhi (rgandhi)" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
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

Is this correct?

Thanks,
Lou

>> Of [email-masked]
Bidirectional LSPs

---

From: Francesco Fondelli <[email-masked]>
Date: Fri, 17 Aug 2012 10:48:49 +0200

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.

---

From: [email-masked]
Date: Fri, 17 Aug 2012 17:31:06 +0800

Hi Francesco, snipped

<fei> It is about c2), in other words, it is Signaling of associated 
congruent LSPs.

Best 

Fei

Francesco Fondelli <[email-masked]> 
发件人:  [email-masked]
2012-08-17 16:48

收件人

Hi All,

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi)
<[email-masked]> wrote:
> 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.
>         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.
> 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.

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 Aug 2012 08:33:46 -0400

Fei,
	It isn't uncommon for authors of WG documents to agree on a change,
publish it, then try to confirm consensus with the WG even though the
formal procedures say it should happen the other way around.  But this
isn't typically done with major changes/additions.

Either way, it's the responsibility of those proposing/supporting a
change to describe the change, and its rationale, to the WG.   My
original objection (on Wednesday) was that you seemed to bring the WG
into the middle of a (perfectly reasonable) private discussion without
any context for the WG. This is why I asked for you/Rakesh to review the
rational for the changes.  (A more typical approach is for the  private
discussion to be summarized on the list, and to include specific
questions/issues for the WG to consider -- but this is up to the
individual not formal procedure.)

It seems this is now happening, at least in piecemeal fashion, so don't
worry about it too much.

Lou

On 8/16/2012 8:55 PM, [email-masked] wrote:
> *Lou Berger <[email-masked]>*
>>>>>                  Title           : RSVP-TE Extensions for
> Associated Bidirectional
>>> LSPs
>>>>>                  Author(s)       : Fei Zhang
>>>>>                           Ruiquan Jing
>>>>>                           Rakesh Gandhi
>>>>>                  Filename        :

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 Aug 2012 08:37:48 -0400

Fei,
	Okay, perhaps I read too much into the reference to FRR in the
discussion and current text.  I'm still trying to understand the
rational for the changes and the issues being addressed.

Any light you, or anyone else, can shed on this would be most appreciate.

Lou

On 8/16/2012 9:19 PM, [email-masked] wrote:
> I do not think we introduce the FRR bypass tunnels in this draft, which
> is used for local protection (RFC4090).
> 
> Do you see them in section 3.2.4 or section 3.2.6, I personally think
> they are GMPLS generic fashion and are totally informational.
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 Aug 2012 10:38:06 -0400

Francesco,

	Nice summary.  I think your last observation, about b and c2 being the
same in the data plane, is the key one.  Up to now, I don't know of
anyone or any draft that has suggested anything but using b for the
control plane representation of co-routed TP paths.  The JWT even called
out using b.

We had a lot of discussion (okay, arguments) about this in the early
days of GMPLS where we debated just using the then practice of using
EROs to provide a bidirectional co-routed data path using 2
unidirectional control plane LSPs.  Obviously the position of using (b)
won out.  Largely because the b approach greatly simplified the control
plane for complex behaviors such as MBB, rerouting, recovery, etc.

It does seem that the draft/proposal is in fact for c2, as confirmed by
Fei's mail.  I was hoping that we could get someone to describe the
issue they are trying to address (perhaps as an intended usage scenario)
as well as why the added control plane complexity is a good idea.
Particularly as all the corner cases need to be addressed.

Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Aug 2012 10:07:26 -0700

Hi,

It's my understanding that this draft started by describing how to instantiate associated bi-directional LSPs by creating an association in signaling between two uni-directional LSPs.  Then came the observation that these two uni-directional LSPs might have congruent paths.  From what I understand, the authors then decided it would be useful to have an option to force two uni-directional LSPs onto congruent paths.

This is when the disconnect occurred.

I think we should simply state that if a co-routed bi-directional LSP is required use RFC 3473, and we should remove the option of forcing two uni-directional LSPs onto congruent paths from the draft.

I also think that the bi-directional FRR material should be removed from the draft.

Thanks,

John 

Sent from my iPhone

> Sent: Thursday, August 16, 2012 3:17 PM
> > Not sure I understand your question.  Per RFC5654 and RFC6373 there
> is a stated need for associated and co-routed MPLS TP transport paths.
> As discussed in RFC6373, RFC3473 already supports co-routed
> bidirectional LSPs.  The draft we're discussing covers associated
> bidirectional.
> >

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 17 Aug 2012 17:28:33 +0000

Thanks Francesco and Lou.

Just like c1 in the initial proposal of the draft for the associated bidirectional LSP, c2 allows the MPLS-TE packet control plane currently deployed in the network (non GMPLS) to be used to provide co-routed  (associated bidirectional) LSP functionality without having to migrate to GMPLS protocol in RFC 3473. 

I do agree with you Lou on some of the complexity that may come with it (MBB, rerouting, recovery, etc.).

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, August 17, 2012 10:38 AM
To: Francesco Fondelli
Cc: Rakesh Gandhi (rgandhi); John E Drake; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Francesco,

	Nice summary.  I think your last observation, about b and c2 being the same in the data plane, is the key one.  Up to now, I don't know of anyone or any draft that has suggested anything but using b for the control plane representation of co-routed TP paths.  The JWT even called out using b.

We had a lot of discussion (okay, arguments) about this in the early days of GMPLS where we debated just using the then practice of using EROs to provide a bidirectional co-routed data path using 2 unidirectional control plane LSPs.  Obviously the position of using (b) won out.  Largely because the b approach greatly simplified the control plane for complex behaviors such as MBB, rerouting, recovery, etc.

It does seem that the draft/proposal is in fact for c2, as confirmed by Fei's mail.  I was hoping that we could get someone to describe the issue they are trying to address (perhaps as an intended usage scenario) as well as why the added control plane complexity is a good idea.
Particularly as all the corner cases need to be addressed.

Lou

On 8/17/2012 4:48 AM, Francesco Fondelli wrote:
> 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:
> 
>>>>      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."
>>>>
>>>> mechanisms for (co-routed) bidirectional LSPs that you'd like to 
>>>> see addressed.
>>>>
>>>>>> 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
>>>>>
>>>>>> A New Internet-Draft is available from the on-line 
>>>>>> Internet-Drafts
>>>> directories.
>>>>>>    association is achieved by defining the new Association Type 
>>>>>> in
>>>> the

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Aug 2012 13:44:48 -0400

Dear Fei,
if we to compare, using Francesco's enumeration, cases b) and c2), then, in my view, differences would be in:

 *
identifiers
 *
coordinated vs. independent monitoring and protection

But I would question whether operators will use independent monitoring and protection on, what looks exactly like, bi-directional co-routed LSP. I think that c2) is not a separate case, but rather "an accident". If an operator wants to build c2) he/she needs to use procedures defined for b).

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 17, 2012 2:31 AM
To: Francesco Fondelli
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi Francesco, snipped

<fei> It is about c2), in other words, it is Signaling of associated congruent LSPs.

Best

Fei

2012-08-17 16:48

收件人
"Rakesh Gandhi (rgandhi)" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [CCAMP] I-D Action:        draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi All,

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Aug 2012 10:52:05 -0700

Rakesh,

1)  In the context of MPLS-TP, the control plane is GMPLS not MPLS.

2)  The distinction between an MPLS control plane and a GMPLS control plane is largely moot;  i.e., it's just RSVP signaling with some different objects and both can co-exist without any issues in a sensible implementation.

3)  Whether you add the objects defined in RFC 3473 or you add the objects in this proposal, you are adding new objects and their associated procedures.

4)  This proposal was considered twelve years ago and rejected in favor of the approach in RFC 3473.

5)  In the context of MPLS-TP, we have spent the past three years arguing that doing the same function in different ways is a Bad Idea(tm).  Why would we want to suddenly embrace two methods of establishing co-routed bidirectional packet LSPs, especially when the new proposal is known to be sub-optimal relative to the existing method?

Thanks,

John

Sent from my iPhone

> From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
> Sent: Friday, August 17, 2012 10:29 AM
> To: Lou Berger; Francesco Fondelli
> Cc: John E Drake; [email-masked]
> Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-
> associated-lsp-04.txt
> 
> Just like c1 in the initial proposal of the draft for the associated
> bidirectional LSP, c2 allows the MPLS-TE packet control plane currently
> deployed in the network (non GMPLS) to be used to provide co-routed
> (associated bidirectional) LSP functionality without having to migrate
> to GMPLS protocol in RFC 3473.
> 
> 	Nice summary.  I think your last observation, about b and c2
> being the same in the data plane, is the key one.  Up to now, I don't
> know of anyone or any draft that has suggested anything but using b for
> the control plane representation of co-routed TP paths.  The JWT even
> called out using b.
> 
> issue they are trying to address (perhaps as an intended usage
> scenario) as well as why the added control plane complexity is a good
> idea.
> >> 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
> >>
> >>
> >>
> 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
> >> 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
> >>
> >>>>>>    Filename        : draft-ietf-ccamp-mpls-tp-rsvpte-ext-
> associated-
> >>>> lsp-04.txt
> >>>>>>    Pages           : 17
> >>>>>>    Date            : 2012-08-15
> >>>>>>
> >>>>>> Abstract:
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-
> rsvpte-
> >>>> ext-
> >>>>>> a
> >>>>>> ssociated-lsp
> >>>>>>
> >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-
> rsvpte-
> >>>> ext-
> >>>>>> a
> >>>>>> ssociated-lsp-04
> >>>>>>
> >>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 17 Aug 2012 12:27:26 -0700

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 <
[email-masked]> wrote:

> keeping the process moving.  Also if the WG disagrees with a change, it can
> always be backed out.
> >

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Aug 2012 13:18:43 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Friday, August 17, 2012 12:27 PM
To: Francesco Fondelli
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

On Fri, Aug 17, 2012 at 12:16 AM, Rakesh Gandhi (rgandhi)
<[email-masked]<mailto:[email-masked]>> wrote:
> From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Rakesh Gandhi (rgandhi); [email-masked]<mailto:[email-masked]>
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>> Behalf Of Lou Berger
>>> Cc: [email-masked]<mailto:[email-masked]>
>>>> From: Lou Berger [mailto:[email-masked]<mailto:[email-masked]>]
>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>>>> Behalf Of [email-masked]<mailto:[email-masked]>
>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>> Cc: [email-masked]<mailto:[email-masked]>
>>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Aug 2012 16:28:10 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, August 17, 2012 1:19 PM
To: Greg Mirsky; Francesco Fondelli
Cc: [email-masked]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Aug 2012 13:49:34 -0700

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:[email-masked]]
Sent: Friday, August 17, 2012 1:28 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi John,

    Regards,
        Greg

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of John E Drake

Thanks,

John

Sent from my iPhone

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

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Aug 2012 17:11:34 -0400

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:[email-masked]]
Sent: Friday, August 17, 2012 1:50 PM
To: Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Greg,

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Aug 2012 14:19:32 -0700

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:[email-masked]]
Sent: Friday, August 17, 2012 2:12 PM
To: John E Drake; Greg Mirsky; Francesco Fondelli
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: David Allan I <[email-masked]>
Date: Fri, 17 Aug 2012 17:24:46 -0400

I think the observation is that coordinated has the most utility in co-routed, and independent has more utility for associated. This is not actually mandated, but true nontheless...

Dave

Sent: Friday, August 17, 2012 2:20 PM

Greg,

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Aug 2012 17:33:58 -0400

John,
as Dave Allan pointed, RFC 6428 does not mandate how coordinated and independent modes should be used. But the very first sentence of Section 3.1 of the document we're discussing says
"The associated bidirectional LSP's forward and backward directions are set up, monitored, and protected independently as required by   [RFC5654<http://tools.ietf.org/html/rfc5654>]." And in RFC 5654, section 1.2.2 I indeed find
"Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points.  The forward and backward directions are setup, monitored, and protected independently.  As a consequence, they may or may not follow the same route (links and nodes) across the network."

I think there's no need for RFC 6428bis. Do you think there's need to revise RFC 5654?

    Regards,
        Greg

Greg,

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Aug 2012 14:33:43 -0700

Dave,

Utility in what sense and are we dealing with an observation or an assertion?

Thanks,

John

Sent from my iPhone

From: David Allan I [mailto:[email-masked]]
Sent: Friday, August 17, 2012 2:25 PM
To: John E Drake; Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Dave

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: David Allan I <[email-masked]>
Date: Fri, 17 Aug 2012 17:48:29 -0400

OK, assertion it is....

If I am on a co-routed path, and I have a bi-directional failure, they are effectively coordinated.
If I have a unidirectional failure it is best to take one hit and switch both directions at the time of failure as some common component in the path needs to be serviced. On that basis many operators would want coordinated mode for co-routed.

That is not necessarily true for bi-directional associated. Coordinated mode is desirable if what the pair of LSPs is carrying will escalate a unidirectional fault to bi-directional anyway (e.g. a router adjacency), but not all associated bi-directional LSPs carry router adjacencies.

my 2 cents
Dave

________________________________
From: John E Drake [mailto:[email-masked]]
Sent: Friday, August 17, 2012 2:34 PM
To: David Allan I; Gregory Mirsky; Greg Mirsky; Francesco Fondelli
Cc: [email-masked]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Dave,

Thanks,

John

Sent from my iPhone

Dave

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: John E Drake <[email-masked]>
Date: Fri, 17 Aug 2012 14:48:38 -0700

Greg,

It's not clear what 'monitored independently' means and whether it edicts coordinated  or independent mode.

It really can't, because as I indicated previously, in both modes there is a bidirectional flow of control packets and in both modes there is a stream of CC/CV packets in each direction.  The only difference is whether if one direction fails, the other direction is forced to fail.

I always thought independent mode was suspect and that requirement for it was derived from the way Y.1731 worked, but I think it is equally suspect for both associated and co-routed.

Thanks,

John

Sent from my iPhone

John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 17 Aug 2012 19:42:04 -0400

Hi John,
"The only difference is whether if one direction fails, the other direction is forced to fail."
Yes. And whether associated bidirectional LSP requires protection as single bidirectional p2p construct or protection applies to each direction independently. But what happens to association in that case? Should protecting unidirectional LSPs be associated with working and protecting unidirectional LSPs of reverse direction before switchover? Consider working L1 A-Z and L2 Z-A are protected by L3 A-Z and L4 Z-A accordingly. L1 and L2 form associated bidirectional p2p LSP. What about L3 and L2, L1 and L4, L3 and L4 - are these the same associated bi-directional LSP or not?

    Regards,
        Greg

PS. Even though most of MPLS WG is likely subscribed to CCAMP list, I'll add MPLS WG to have opinions and comments from it.

Sent: Friday, August 17, 2012 2:49 PM

Greg,

Thanks,

John

Sent from my iPhone

John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi John,

    Regards,
        Greg

Thanks,

John

Sent from my iPhone

Hi Francesco,

Regards,
Greg

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: Francesco Fondelli <[email-masked]>
Date: Sat, 18 Aug 2012 18:33:10 +0200

Hi Greg,

well, s/data-plane/ILM\\/NHLFE/

:-)

Actually, I meant the forwarding component of the data-plane
... and whether CC/CV is part of the data-plane or not I'm sure
is another point for debate...

BTW, I'm following the interesting discussion about BFD modes
and LSP types.

thank you
ciao
FF

On Fri, Aug 17, 2012 at 9:27 PM, Greg Mirsky <[email-masked]> wrote:
> 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
> <[email-masked]> wrote:
>>
>> Hi All,
>>

---

From: Francesco Fondelli <[email-masked]>
Date: Sat, 18 Aug 2012 18:54:11 +0200

Thank you.  I think we are on the same page.

Ciao
Fra

---

From: [email-masked]
Date: Mon, 20 Aug 2012 19:32:21 +0800

Hi Greg

See in line with <fei>

Thanks

Fei

Gregory Mirsky <[email-masked]> 
2012-08-18 01:44

收件人
"[email-masked]" <[email-masked]>, Francesco Fondelli 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [CCAMP] I-D Action: 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Dear Fei,
if we to compare, using Francesco's enumeration, cases b) and c2), then, 
in my view, differences would be in:
identifiers
<fei>Yeah, the identifiers are used in control plane for association and 
the label forwarding is the same in the data plane.
coordinated vs. independent monitoring and protection
<fei>Actually, both of them are addressed in this version, see section 
3.2.4 for independent and section 3.2.6 for coordinated.

But I would question whether operators will use independent monitoring and 
protection on, what looks exactly like, bi-directional co-routed LSP. I 
think that c2) is not a separate case, but rather "an accident". If an 
operator wants to build c2) he/she needs to use procedures defined for b).

<fei>We need to heare opinions from the operators, and one of Rekesh's 
argument is listed below for reference:
<RG1> It is fine to have non co-routed as default. RFC 3473 is a GMPLS 
signaling procedure. It may not be optimal  to have two different 
signaling procedures, one for non co-routed (ext associated object) and 
one for co-routed (RFC 3473) procedures. By adding a flag for co-routed, 
same signaling (ext associated object) can be used for both which is nice. 
We believe comparing of RRO can be misleading because two LSPs can be on 
the same path even though provisioned to be non co-routed. 
 
    Regards,
        Greg

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]

Hi Francesco, snipped 

Best 

Fei 

收件人

Hi All,

In my opinion:

Am I missing something?

thank you
ciao
fra

PS

---

From: Lou Berger <[email-masked]>
Date: Mon, 20 Aug 2012 14:00:43 -0400

On 8/20/2012 7:32 AM, [email-masked] wrote:
> On 8/17/2012 1:44 PM, Gregory Mirsky wrote:
> But I would question whether operators will use independent monitoring
> and protection on, what looks exactly like, bi-directional co-routed
> LSP. I think that c2) is not a separate case, but rather "an accident".
> If an operator wants to build c2) he/she needs to use procedures defined
> for b).
> 
> same signaling (ext associated object) can be used for both which is
> nice. We believe comparing of RRO can be misleading because two LSPs can
> be on the same path even though provisioned to be non co-routed.
>  
>     Regards,
>         Greg

Fei,
	I personally think we have plenty of input on requirements, at least in
the TP context, captured in rfc5654.

At this point, if someone wants to add a second control plane mechanism
for controlling co-routed bidirectional, I (as co-chair) think, they
need to make the case for it and get WG buy-in.  In other words, I
believe *current* working group consensus does *not* support introducing
a second co-route bidirectional LSP signaling mechanism.

I believe Rakesh said he'd read up on what's already supported and get
back to the WG (presumably if he thinks another mechanism is justified).
Of course, you and anyone else are free to make the case yourself.

Lou

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 21 Aug 2012 21:53:00 +0000

All -

It is interesting that we have before us a draft which has both TP and TE
in the name.  I believe that has much to do with the disagreements here.

I've spoken with operators who are interested in applying some but not all
aspects of TP to TE.

The aspects that they want are bidirectionality and "better OAM" where the
details of this may vary, but generally include BFD be it of the TP-in-GAL
variety or just BFD bootstrapped (as normal) across a bidirectional
forwarding adjacency.

One aspect of TE that many would like to preserve is FRR.  Both node and
link.  That is they don't care if in a failure things are not strictly
co-routed.  And some have uses for bidirectional adjacencies that aren't
co-routed.

I also note in passing that some want no-php, but also see cases where php
servers their needs and is more efficient on their deployed hardware.

Personally, I see no need to update RFC5654 as I'm happy to have all this
fall under the ruberic of TE.

But I very much want to have a means of signaling bidirectional TE LSPs,
preserving the ability to have node and link FRR.  I also think it would
be wrong to call this TP.  Let TP stand as the narrowly drawn profile it
is.  But the middle ground between TE and TP will get filled in.  And that
can all be extensions to TE.

...George

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Aug 2012 08:40:03 -0400

Hi George,
	I had a little trouble understanding what additional functionality you
were identifying in your message, but after rereading it a few times, I
think I may understand what you are looking for. Unless I'm mistaken it
comes down to:
> want to have a means of signaling bidirectional TE LSPs,
> preserving the ability to have node and link FRR.

And this is independent from co-routed or not.

Is this correct?

Assuming it is, I think there are two related use cases:

1) When the bidirectional data paths are established using a GMPLS
bidirectional LSP, and

2) When the bidirectional data paths are established using the extension
defined in rsvpte-ext-associated-lsp-03 (note not -04)

In the case of (1), GMPLS birdirectional LSPs with FRR, I think you're
right. This would require additional specification. Clearly (as John
suggested) discussion on such mechanisms would need to at least start
based on an independent (new) draft. I personally don't think there's
any reason why someone couldn't author and submit such an independent draft.

In the case of (2), as you're not suggesting co-routed recovery, why
can't FRR just be used with procedures defined in
rsvpte-ext-associated-lsp-03 (note not -04)?  It's even possible to
specify the ERO and FRR related objects for the reverse/upstream LSP
using the REVERSE_LSP object. Are you just suggesting the need for an
informative "Recovery Considerations" section that covers interaction of
associated bidirectional LSPs with recovery/FRR?  Or something more?

Lou