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

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Lou,

Thank you for your feedbacks.

Fei and I are discussed the possibility but could not attend the meeting in Vancouver.

We will start a new email thread on the changes.

Thanks,
Rakesh


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

Fei/Rakesh,

	I'd like to take a step back on this thread. This mail seems to be bringing the WG into the middle of a private discussion. I personally think the *right* way to have brought this  *private* discussion to the attention of the WG would be to either:
(a) start the discussion anew, this time including the WG or
(b) use the meeting time in Vancouver to raise the discussion (Fei,
    I know you weren't there, but Rakesh or someone else could have
    presented.)

So where do we go from here?

I'd like to ask that someone (Rakesh, Fei, etc.) review each of the proposed changeand 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 (as co-chair)

On 7/30/2012 10:03 PM, [e-mail] wrote:
> 
> 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)" <[e-mail]>*
> 
> 2012-07-30 23:59
> 
> 	
> 收件人
> 	"[e-mail]" <[e-mail]>
> 抄送
> 	"Eric Osborne (eosborne)" <[e-mail]>, 
> "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[e-mail]>, "Robert Sawaya (rsawaya)"
> <[e-mail]>, "George Swallow (swallow)" <[e-mail]>, 
> "[e-mail]" <[e-mail]>
> 主题
> 	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:* [e-mail] [mailto:[e-mail]] *
> Sent:* Wednesday, July 25, 2012 11:42 AM*
> To:* Rakesh Gandhi (rgandhi)*
> Cc:* Eric Osborne (eosborne); [e-mail]; 
> [e-mail]; Robert Sawaya (rsawaya); George Swallow 
> (swallow);
> [e-mail]*
> 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)" <* * [e-mail] * 
> <mailto:[e-mail]> *>*
> 
> 2012-07-25 05:49
> 
> 	
> 收件人
> 	" [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >
> 抄送
> 	"Eric Osborne (eosborne)" < [e-mail] 
> <mailto:[e-mail]> >, " [e-mail] 
> <mailto:[e-mail]> " < [e-mail] 
> <mailto:[e-mail]> >, " [e-mail] 
> <mailto:[e-mail]> " < [e-mail] 
> <mailto:[e-mail]> >, "Robert Sawaya (rsawaya)" < 
> [e-mail] <mailto:[e-mail]> >, "George Swallow 
> (swallow)" < [e-mail] <mailto:[e-mail]> >, "
> [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >
> 主题
> 	RE: Comments on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03
> 
> 
>  
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> Thank you Fei  for detailed comments.
>  
> Please see inline..<RG>..
>   *
> From:* [e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]] <mailto:[mailto:[e-mail]]> 
> *
> Sent:* Tuesday, July 24, 2012 10:44 AM*
> To:* Rakesh Gandhi (rgandhi)*
> Cc:* Eric Osborne (eosborne); [e-mail] 
> <mailto:[e-mail]> ; [e-mail] 
> <mailto:[e-mail]> ; Robert Sawaya (rsawaya); George Swallow 
> (swallow); [e-mail] <mailto:[e-mail]> *
> 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 easier J 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
> <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)" <* * [e-mail] * 
> <mailto:[e-mail]> *>*
> 
> 2012-07-21 23:33
> 
> 	 
> 
> 
> 收件人
> 	" [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >
> 抄送
> 	"Eric Osborne (eosborne)" < [e-mail] 
> <mailto:[e-mail]> >, " [e-mail] 
> <mailto:[e-mail]> " < [e-mail] 
> <mailto:[e-mail]> >, " [e-mail] 
> <mailto:[e-mail]> " < [e-mail] 
> <mailto:[e-mail]> >, "Robert Sawaya (rsawaya)" < 
> [e-mail] <mailto:[e-mail]> >, "George Swallow 
> (swallow)" < [e-mail] <mailto:[e-mail]> >, "
> [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >
> 主题
> 	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:* [e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]] <mailto:[mailto:[e-mail]]> 
> *
> Sent:* Wednesday, July 04, 2012 10:57 PM*
> To:* Rakesh Gandhi (rgandhi)*
> Cc:* Eric Osborne (eosborne); [e-mail] 
> <mailto:[e-mail]> ; [e-mail] 
> <mailto:[e-mail]> ; Robert Sawaya (rsawaya); George Swallow 
> (swallow); [e-mail] <mailto:[e-mail]> *
> 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)" <* * [e-mail] * 
> <mailto:[e-mail]> *>*
> 
> 2012-07-04 20:46
> 
> 	 
> 
>  
> 
> 
> 收件人
> 	" [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >, "
> [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >, " 
> [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >, " 
> [e-mail] <mailto:[e-mail]> " < 
> [e-mail] <mailto:[e-mail]> >
> 抄送
> 	"Eric Osborne (eosborne)" < [e-mail] 
> <mailto:[e-mail]> >, "George Swallow (swallow)" < 
> [e-mail] <mailto:[e-mail]> >, rsawaya < 
> [e-mail] <mailto:[e-mail]> >
> 主题
> 	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
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp