Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

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

Hi Rakesh

Snipped the other parts for easy reading, sorry for the delayed response 

<RG3> There are applications that require co-routed LSPs. So I think we 
should have a flag to indicate that LSPs must be co-routed, else node will 
send a path error for example if request cannot be met.  I agree with you 
about complexity with double sided provisioning model though. 

<fei> Since you believe that a common mechanism used for the non-corouted 
and corouted cases is useful, we will add the texts in the next version.

<RG3> Ok, we probably should add use cases for various methods. I can see 
method 1 being used for setting up bidirectional LSPs but I am not sure 
about method 2 for example. One worry is that different methods can lead 
to interop issues if one vendor implements method 1 and second vendor 
method 2.
Association object is being used for different association types (RFC 
4872: type 1: Recovery), (RFC 4873- type 2: Resource sharing), etc. and 
these RFCs define specific procedures for the given association type. So 
IMHO, it may be ok to define a stricter procedure for populating ext 
association object for the new Bidirectional LSPs association type.

<fei> Method 2 works well, and the only difference is t how to represent 
the global unique identifier. For the association is based on the full 
match of the EA objects, the EA object is just copied from the path 
message into another path message in single sided provisioning model. As 
to the doubled sided provisioning model, the EA objects is also the same. 
IMHO, there is no interop issues, or do I have some misunderstanding? 

Yeah, we can define a stricter prodedure, I am not sure this is a good way 
in standard, need more feedback from the WG.

Cheer

Fei

"Rakesh Gandhi (rgandhi)" <[email-masked]> 
2012-08-01 01:24

收件人
"[email-masked]" <[email-masked]>
抄送
"Eric Osborne (eosborne)" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"Robert Sawaya (rsawaya)" <[email-masked]>, "George Swallow (swallow)" 
<[email-masked]>, "[email-masked]" <[email-masked]>, CCAMP 
<[email-masked]>
主题
RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Hi Fei,
 
Thanks for your kind reply. Please see inline..<RG3>..
 
<Snipped email to focus on open items>

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 30, 2012 10:04 PM
To: Rakesh Gandhi (rgandhi)
Cc: Eric Osborne (eosborne); [email-masked]; 
[email-masked]; Robert Sawaya (rsawaya); George Swallow (swallow); 
[email-masked]; CCAMP
Subject: RE: Comments on 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Thank you Rakesh for sharing your idea, I think we are roughly in 
agreement and need to hear more voices from the WG. :) 

See inline <fei></fei>

Best 

Fei 

2) Define one flag for co-routed or non-corouted. If the co-routed bidir 
is the default behavior, why not using the procedure defined in RFC3473? I 
am afraid it is hard 
to persuade the WG to do so. Maybe the better way is that non-corouted 
bidir is the default, and the set of the co-routed flag only means that it 
is recommended, not mandatory, the checking whether the LSP is co-routed 
can be done by comparing the RRO objects. What is your opinion? 
<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. 

<fei> 
Sorry that what I suggested maybe mislead you, the following descripitons 
are more accurate. :) 
 1)The default behavior (non-corouted) means that it is not required to be 
co-routed. In other words, it is also OK that the two paths are along the 
same path
 
. 
<RG3> Agree.

 2)The flag set means that co-routed is recommended. In other words, the 
reverse LSP SHOULD be established in the same path as much as possible. If 
the flag set means 
that co-routed is mandatory,the procedures will be very complex in double 
sided provisioning model. 
</fei> 
<RG3> There are applications that require co-routed LSPs. So I think we 
should have a flag to indicate that LSPs must be co-routed, else node will 
send a path error for example if request cannot be met.  I agree with you 
about complexity with double sided provisioning model though. 

3)As to the tuple of <lower ip address, high ip address, association id>, 
yeah, it is one kind of implementation, but there are potential some other 
realizations, like using one of the router id plus the tunnel id. I think 
we had better not restrict the execution to such a narrow scope. What 
about the EA format listed below? 

        0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Length             | Class-Num(199)|  C-Type (TBA) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Association Type        |       Association ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IPv4 Association Source                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Global Association Source                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Extended Association Flags.    |Extended Association ID ...    | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |....(continue)                                                 :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<RG> Do you mean to have extended association ID as tunnel ID (16 bits) + 
IP address (32 bits) in this object? 
Please see inline below..<RG1>.. 

<fei> 
No. I want to say that this format of EA objects can accomodate more kinds 
of implementations. Like 

1)Association ID: user provisioned idential value; Association Source: the 
lowe ip address; EA ID: the higher IP address. As you suggested 

2)Association ID: tunnel ID or user provisioned value; Association 
Source:Tunnel sender address or user provisioned; EA ID: be empty or LSP 
ID or any other information. 

3)The potential other implementations... 

IMHO, the EA ID can be IP address or any other values in the context of 
Association Source plus Association ID, which is backward compatible. 

</fei> 
<RG3> Ok, we probably should add use cases for various methods. I can see 
method 1 being used for setting up bidirectional LSPs but I am not sure 
about method 2 for example. One worry is that different methods can lead 
to interop issues if one vendor implements method 1 and second vendor 
method 2.
Association object is being used for different association types (RFC 
4872: type 1: Recovery), (RFC 4873- type 2: Resource sharing), etc. and 
these RFCs define specific procedures for the given association type. So 
IMHO, it may be ok to define a stricter procedure for populating ext 
association object for the new Bidirectional LSPs association type.
 
Thanks,
Rakesh

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 3 Aug 2012 12:11:56 +0000

Thanks Fei. We are almost there. Please see inline..<RG4>.

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 03, 2012 5:16 AM
To: Rakesh Gandhi (rgandhi)
Cc: CCAMP; Eric Osborne (eosborne); [email-masked]; [email-masked]; Robert Sawaya (rsawaya); George Swallow (swallow); [email-masked]
Subject: RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Hi Rakesh

<RG3> There are applications that require co-routed LSPs. So I think we should have a flag to indicate that LSPs must be co-routed, else node will send a path error for example if request cannot be met.  I agree with you about complexity with double sided provisioning model though.

<fei> Since you believe that a common mechanism used for the non-corouted and corouted cases is useful, we will add the texts in the next version.
<RG4> This is great. Thanks.

<RG3> Ok, we probably should add use cases for various methods. I can see method 1 being used for setting up bidirectional LSPs but I am not sure about method 2 for example. One worry is that different methods can lead to interop issues if one vendor implements method 1 and second vendor method 2.
Association object is being used for different association types (RFC 4872: type 1: Recovery), (RFC 4873- type 2: Resource sharing), etc. and these RFCs define specific procedures for the given association type. So IMHO, it may be ok to define a stricter procedure for populating ext association object for the new Bidirectional LSPs association type.

<fei> Method 2 works well, and the only difference is t how to represent the global unique identifier. For the association is based on the full match of the EA objects, the EA object is just copied from the path message into another path message in single sided provisioning model. As to the doubled sided provisioning model, the EA objects is also the same. IMHO, there is no interop issues, or do I have some misunderstanding?

Yeah, we can define a stricter prodedure, I am not sure this is a good way in standard, need more feedback from the WG.
<RG4> I agree that if both vendors implement say method 1 or both vendors implement say method 2 then they would interoperate, and  ext EA objects are the same. But method 1 and method 2 may not interoperate together.  Not sure if we want to have a separate flag to indicate if ext association object is populated with method 1 or 2 to cover this case?   It is fine to have more than one method in the draft for flexibility and future use but good to elaborate on the possible use case if we know of any.
Thanks,
Rakesh

Cheer

Fei

"Rakesh Gandhi (rgandhi)" <[email-masked]<mailto:[email-masked]>>

2012-08-01 01:24

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

抄送

"Eric Osborne (eosborne)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Robert Sawaya (rsawaya)" <[email-masked]<mailto:[email-masked]>>, "George Swallow (swallow)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, CCAMP <[email-masked]<mailto:[email-masked]>>

主题

Hi Fei,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, July 30, 2012 10:04 PM
To: Rakesh Gandhi (rgandhi)
Cc: Eric Osborne (eosborne); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Sawaya (rsawaya); George Swallow (swallow); [email-masked]<mailto:[email-masked]>; CCAMP
Subject: RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Thank you Rakesh for sharing your idea, I think we are roughly in agreement and need to hear more voices from the WG. :)

See inline <fei></fei>

Best

Fei

2) Define one flag for co-routed or non-corouted. If the co-routed bidir is the default behavior, why not using the procedure defined in RFC3473? I am afraid it is hard
to persuade the WG to do so. Maybe the better way is that non-corouted bidir is the default, and the set of the co-routed flag only means that it is recommended, not mandatory, the checking whether the LSP is co-routed can be done by comparing the RRO objects. What is your opinion?
<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.

<fei>
Sorry that what I suggested maybe mislead you, the following descripitons are more accurate. :)
1)The default behavior (non-corouted) means that it is not required to be co-routed. In other words, it is also OK that the two paths are along the same path

.
<RG3> Agree.

2)The flag set means that co-routed is recommended. In other words, the reverse LSP SHOULD be established in the same path as much as possible. If the flag set means
that co-routed is mandatory,the procedures will be very complex in double sided provisioning model.
</fei>
<RG3> There are applications that require co-routed LSPs. So I think we should have a flag to indicate that LSPs must be co-routed, else node will send a path error for example if request cannot be met.  I agree with you about complexity with double sided provisioning model though.

3)As to the tuple of <lower ip address, high ip address, association id>, yeah, it is one kind of implementation, but there are potential some other realizations, like using one of the router id plus the tunnel id. I think we had better not restrict the execution to such a narrow scope. What about the EA format listed below?

       0                   1                   2                   3

<RG> Do you mean to have extended association ID as tunnel ID (16 bits) + IP address (32 bits) in this object?
Please see inline below..<RG1>..

<fei>
No. I want to say that this format of EA objects can accomodate more kinds of implementations. Like

1)Association ID: user provisioned idential value; Association Source: the lowe ip address; EA ID: the higher IP address. As you suggested

2)Association ID: tunnel ID or user provisioned value; Association Source:Tunnel sender address or user provisioned; EA ID: be empty or LSP ID or any other information.

IMHO, the EA ID can be IP address or any other values in the context of Association Source plus Association ID, which is backward compatible.

</fei>
<RG3> Ok, we probably should add use cases for various methods. I can see method 1 being used for setting up bidirectional LSPs but I am not sure about method 2 for example. One worry is that different methods can lead to interop issues if one vendor implements method 1 and second vendor method 2.
Association object is being used for different association types (RFC 4872: type 1: Recovery), (RFC 4873- type 2: Resource sharing), etc. and these RFCs define specific procedures for the given association type. So IMHO, it may be ok to define a stricter procedure for populating ext association object for the new Bidirectional LSPs association type.

Thanks,
Rakesh

---

From: [email-masked]
Date: Wed, 8 Aug 2012 15:41:18 +0800

Thank you Rakesh for your prompt response :)

Snipped the agreeable parts, see in line with <fei1>

<RG4> I agree that if both vendors implement say method 1 or both vendors 
implement say method 2 then they would interoperate, and  ext EA objects 
are the same. But method 1 and method 2 may not interoperate together. Not 
sure if we want to have a separate flag to indicate if ext association 
object is populated with method 1 or 2 to cover this case?   It is fine to 
have more than one method in the draft for flexibility and future use but 
good to elaborate on the possible use case if we know of any.

<fei1> IMHO, the only difference is the unique representation of the 
association, using SA+association-id(ID is unique under SA )or 
SA+DA+association-id (ID is unique under the combination of SA and DA) 
which is more stricter. I agree that we had better adopting one of them 
because of the interop issue.

Let's consider the auto-mesh tunnels which you provided in the previous 
email.  "<RG> There is a use case for auto-mesh tunnels where source node 
may originate tunnels to many destinations using the same association 
source and association-id. In this case, different values for extended 
association ID provide unique extended association object."
Can you clarify what is the benefits of using the same association-id 
(different association-id works well also), so that we can persuade the WG 
that this strict implementation is a better choice and add the usecase if 
necessary.

Or any other usecases?

Please do not hesitate to let me know if I have a mistake

Best regards

Fei

2012-08-03 20:11

收件人
"[email-masked]" <[email-masked]>
抄送
CCAMP <[email-masked]>, "Eric Osborne (eosborne)" <[email-masked]>, 
"[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "Robert Sawaya (rsawaya)" 
<[email-masked]>, "George Swallow (swallow)" <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Cc: CCAMP; Eric Osborne (eosborne); [email-masked]; 
[email-masked]

Hi Rakesh 

Yeah, we can define a stricter prodedure, I am not sure this is a good way 
in standard, need more feedback from the WG. 
<RG4> I agree that if both vendors implement say method 1 or both vendors 
implement say method 2 then they would interoperate, and  ext EA objects 
are the same. But method 1 and method 2 may not interoperate together. Not 
sure if we want to have a separate flag to indicate if ext association 
object is populated with method 1 or 2 to cover this case?   It is fine to 
have more than one method in the draft for flexibility and future use but 
good to elaborate on the possible use case if we know of any.
Thanks,
Rakesh

Cheer 

Fei 

收件人

Hi Fei, 

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 30, 2012 10:04 PM
To: Rakesh Gandhi (rgandhi)
Cc: Eric Osborne (eosborne); [email-masked]; [email-masked]
; Robert Sawaya (rsawaya); George Swallow (swallow); [email-masked]; 
CCAMP
Subject: RE: Comments on 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03 

See inline <fei></fei>

Best 

Fei 

<fei> 
  
. 
<RG3> Agree. 

       0                   1                   2                   3

<fei> 

</fei> 
  
Thanks, 
Rakesh

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 8 Aug 2012 13:14:44 +0000

Hi Fei,

Thanks for your insight. I understand what you are saying, please see inline..<RG5>

Sent: Wednesday, August 08, 2012 3:41 AM

<fei1> IMHO, the only difference is the unique representation of the association, using SA+association-id(ID is unique under SA )or SA+DA+association-id (ID is unique under the combination of SA and DA) which is more stricter. I agree that we had better adopting one of them because of the interop issue.

Let's consider the auto-mesh tunnels which you provided in the previous email.  "<RG> There is a use case for auto-mesh tunnels where source node may originate tunnels to many destinations using the same association source and association-id. In this case, different values for extended association ID provide unique extended association object."
Can you clarify what is the benefits of using the same association-id (different association-id works well also), so that we can persuade the WG that this strict implementation is a better choice and add the usecase if necessary.

<RG5> For single sided provisioning, where remote end simply copies the received Ext Association Object, association-id can be unique for SA. But for double sided provisioning, where association-id is used to glue the two LSPs – forward and reverse direction LSPs, association-id is used to identify the matching LSPs and hence need to be unique per SA+DA.
Similar to static tunnels, auto-tunnel mesh can also be provisioned using identical association-ids on both sides. This way same method works for both.
Thanks,
Rakesh

Or any other usecases?

Best regards

Fei

2012-08-03 20:11

收件人

抄送

CCAMP <[email-masked]<mailto:[email-masked]>>, "Eric Osborne (eosborne)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Robert Sawaya (rsawaya)" <[email-masked]<mailto:[email-masked]>>, "George Swallow (swallow)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Cc: CCAMP; Eric Osborne (eosborne); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Robert Sawaya (rsawaya); George Swallow (swallow); [email-masked]<mailto:[email-masked]>

Hi Rakesh

Cheer

Fei

2012-08-01 01:24

收件人

抄送

主题

Hi Fei,

See inline <fei></fei>

Best

Fei

<fei>

.
<RG3> Agree.

      0                   1                   2                   3

<fei>

</fei>

Thanks,
Rakesh

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Aug 2012 12:34:12 -0400

Fei/Rakeash,
	Co-routed associated is already supported in 3473 using bidirectional
LSPs. So, to signal co-routed all that needs to be done is use the
existing procedures.  What issue is being addressed (i.e., function
being added) by adding the proposed co-routed related mechanisms?

Keep in mind, it's generally a *very* bad idea to define 2 mechanisms in
the same protocol for the same function.

Lou

On 8/3/2012 5:16 AM, [email-masked] wrote:
> should have a flag to indicate that LSPs must be co-routed, else node
> will send a path error for example if request cannot be met.  I agree
> with you about complexity with double sided provisioning model though.
> 
> <fei> Since you believe that a common mechanism used for the
> non-corouted and corouted cases is useful, we will add the texts in the
> next version.

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 15 Aug 2012 17:06:45 +0000

Hi Lou,

Thank you for your comments.

As you indicated in another email,  it will be easier to start with a new email thread or perhaps a presentation.

Thanks,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 12:34 PM
To: [email-masked]
Cc: Rakesh Gandhi (rgandhi); Robert Sawaya (rsawaya); [email-masked]; CCAMP; [email-masked]
Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Fei/Rakeash,
	Co-routed associated is already supported in 3473 using bidirectional LSPs. So, to signal co-routed all that needs to be done is use the existing procedures.  What issue is being addressed (i.e., function being added) by adding the proposed co-routed related mechanisms?

Keep in mind, it's generally a *very* bad idea to define 2 mechanisms in the same protocol for the same function.

Lou

On 8/3/2012 5:16 AM, [email-masked] wrote:
> <RG3> There are applications that require co-routed LSPs. So I think 
> we should have a flag to indicate that LSPs must be co-routed, else 
> node will send a path error for example if request cannot be met.  I 
> agree with you about complexity with double sided provisioning model though.
> 
> non-corouted and corouted cases is useful, we will add the texts in 
> the next version.

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Aug 2012 13:09:50 -0400

Rakesh,
	Agreed.  I sent this mail before realizing the full scope of the
discussion/proposed changes.  I'll look to your (the) new thread to
resolve this comment.

Thanks,
Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 15 Aug 2012 10:07:44 -0700

Lou,

This sounds like a textbook definition of 'feature creep' and is a really bad idea.

Thanks,

John

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lou Berger
> Sent: Wednesday, August 15, 2012 9:34 AM
> Cc: CCAMP; [email-masked]; Robert Sawaya (rsawaya);
> [email-masked]
> 	Co-routed associated is already supported in 3473 using
> bidirectional LSPs. So, to signal co-routed all that needs to be done
> is use the existing procedures.  What issue is being addressed (i.e.,
> function being added) by adding the proposed co-routed related
> mechanisms?
> 
> Keep in mind, it's generally a *very* bad idea to define 2 mechanisms
> in the same protocol for the same function.
> 
> Lou
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp