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

From: [email-masked]
Date: Tue, 31 Jul 2012 10:03:45 +0800

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

"Rakesh Gandhi (rgandhi)" <[email-masked]> 
2012-07-30 23:59

收件人
"[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]>
主题
RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Thanks Fei for your kind reply. Sorry for the delay (as I was away).
 
Please see inline..<RG1>..
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 11:42 AM
To: Rakesh Gandhi (rgandhi)
Cc: 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

Rakesh 

Thanks for your nice interpretation, and I can see there are at least 
three parts that need to be revised in the next version 

1) Define only one association type, and the single sided and double sided 
provisioning models are represented by 1 flag.  Agree 
<RG1> Great, thanks.

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

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>

The other comments are lined with <fei> in the former email 

Best 

Fei 

"Rakesh Gandhi (rgandhi)" <[email-masked]> 
2012-07-25 05:49 

收件人
"[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]> 
主题
RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Thank you Fei  for detailed comments. 
  
Please see inline..<RG>.. 
  
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2012 10:44 AM
To: Rakesh Gandhi (rgandhi)
Cc: 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 

Rakesh 

Thanks for your constructive inputs, it is really a pity that we can not 
talk with each other face to face. 
<RG> Yeap, that would make it much easierJ 
In order to reflect your idea correctly, I need to double check with you 
before incorporating them into the draft. :) 

Slide 3: 

The EA Object defined in the draft 
http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-03 has an variable 
"Extended Association ID" field, 

which is restricted to be IP address and FLAGS in your proposal and the 
length is fixed, right? 
<RG> Right. It will be fixed length, explicitly defined. 
Slide 4: 

IPv4 Association source: 

In the double sided provisioning model, what if the lower IP address that 
the two end points see is different? IMHO, the sender address can be any 
interface address or router id of this node (for example A see the 
interface address, but Z see the router id of node A) 

<RG> It is up to the user and implementation. One option is that similar 
to the association ID, user provisions association source on the router 
and ensures same value is configured on two ends of the bi-directional 
LSP. That way interop issues can be avoided. 

<fei>If the association source is user provisions, it can be diffferent 
from the lower ip address, which is the same way as we described in the 
current version of the draft. And I think it is a better choice since the 
signaling procedure is much simpler. 
<RG1> User provisioned values  can override the default behavior. It is 
nice to have a default behavior in the draft as it can minimize number of 
configurations on a router and potential provisioning errors.
<fei>
See inline above, we need to find a better way to descirbe the Association 
Source field so that the implementations can be more flexible and let's 
hear about other voices from the WG. :)
</fei>

In the paragraph of Extended association ID- IP address 

Since your proposal is to put the higher IP address in this field, I do 
not understand why extended association id received is different than sent 

. Can you interpret it more clearly? 
<RG> It should not be different. This is in-line with your comment above 
for the association source, i.e. what if two end points choose different 
values. In that case value received from the association source wins. This 
part can be  optional. 

<fei>If it is different, I still do not understand the tie-breaker rule 
here. Even it really works, the signaling procedure is much more 
complicated 
<RG1> Ext association IDs should not be different if draft defines a rule 
with lower and higher IP address. So you are right, we can remove this 
point. 
<fei>
Got it.
</fei>
Thanks,
Rakesh

Slide 6: 
Sentence 1, do you mean the backup tunnel is co-routed (one signaling) or 
associated (two signaling, but the path is the same)? 
<RG> Some applications may require co-routed LSPs. In that case, backup 
tunnels may also need to be co-routed as a requirement.

Sentence 2 and 3, technically right, but I do not understand why corouted 
must be used here, for the same latency of the two directions? 
<RG> Application may have this as a requirement. Signaling should support 
both co-routed or non-co-routed LSPs. 
Sentence 4, why non-routed LSP can not be used here for OAM purpose? 
<RG> It can be. But OAM could potentially have different handling. 
<fei> IMHO, it is the same handling since the OAM packet follows the data 
packet  path, and the forwarding table  (non-co or corout )  looks the 
same when the binding is successful 

Slide 8; 
I do not think the draft preclude the usage of Protection Object in the 
current verion, and the usecase can be added in the next version if you 
like. 
<RG> Yes, that would be good.  This way less interop issues to worry about
J 
Your proposal is excellent and easy to implement, but I am not totally 
convinced because of the listed reason blow 

(1) According to my understanding, the association can work without the 
field of Extended Association ID (IP address), and what is the benefits of 
the interoperability for 
using two IP address? 
<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. 
<Fei> Got it ,thanks 
(2)The suggestion of using flags is very good, but we need to list the 
motivation why corouted and non-corouted should be distinct. 
<RG> This is on page 6 of the file I had sent. Inter-domain LSP with 
loose-hop ERO is one example. 
Thanks Fei, 
Rakesh

Hope you shed some light on me, and we can have agreement quickly. 

Best regards 

Fei 

"Rakesh Gandhi (rgandhi)" <[email-masked]> 
2012-07-21 23:33 

收件人
"[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]> 
主题
RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03

Thanks Fei for your kind reply. 
 
Please see the attached document that describes the set of rules that can 
be standardized to populate the extended association object for 
bi-directional LSP setup. This will greatly help with the interoperability 
for tunnel setup. 
 
Thanks for accommodating these inputs in the draft. 
 
Regards, 
Rakesh 
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2012 10:57 PM
To: Rakesh Gandhi (rgandhi)
Cc: 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 

Be glad that you are also interested in this draft and your opinions are 
important to us. 

As to the plan, I am afraid I can not attend the IETF meeting in Vancouver 
for the limited budget, but I would like to upload a new version 
reflecting the comments collected 
on and off the mailinglist recently, then ask for last call. 

Any thinking coming from you are welcome  ^-^ 

Best regards 

Fei 

"Rakesh Gandhi (rgandhi)" <[email-masked]> 
2012-07-04 20:46 

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

Hello Authors of the draft, 

We have taken a close look at the 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03. 

We have some comments on this draft that we like to share with you. There 
is an IETF meeting end of this Month in Vancouver, not sure if you are 
planing to attend. 

Can you please advise your plans and next steps for this draft? If you are 
planning to publish updated draft, may be we should sync up on our 
thinking before that? 

Thanks a lot, 
Rakesh Gandhi

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 31 Jul 2012 17:24:22 +0000

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

<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