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

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

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

From: [e-mail] [mailto:[e-mail]]
Sent: Friday, August 03, 2012 5:16 AM
To: Rakesh Gandhi (rgandhi)
Cc: CCAMP; 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


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.
<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)" <[e-mail]<mailto:[e-mail]>>

2012-08-01 01:24

收件人

"[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]>>, CCAMP <[e-mail]<mailto:[e-mail]>>

主题

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Monday, July 30, 2012 10:04 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]>; 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