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

[[e-mail]]

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)" <[e-mail]> 
2012-08-01 01:24

收件人
"[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]>, CCAMP 
<[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]] 
Sent: Monday, July 30, 2012 10:04 PM
To: Rakesh Gandhi (rgandhi)
Cc: Eric Osborne (eosborne); [e-mail]; 
[e-mail]; Robert Sawaya (rsawaya); George Swallow (swallow); 
[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