Re: [CCAMP] Discussion on how to carry the Global_ID

Fei,
	See below.

On 2/2/2012 8:37 PM, zhang.fei3@zte.com.cn wrote:
> 
> Lou
> 
> Thanks for your response, please see the reponses in-line with
> <fei></fei> to check whether I make a mistake.
> 
> Best regards
> 
> Fei
> 
> 
> *Lou Berger <lberger@labn.net>*
> 
> 2012-02-02 22:29
> 
> 	
> 收件人
> 	zhang.fei3@zte.com.cn
> 抄送
> 	"ccamp@ietf.org" <ccamp@ietf.org>
> 主题
> 	Re: [CCAMP] Discussion on how to carry the Global_ID
> 
> 
> 	
> 
> 
> 
> 
> 
> Fei,
>                 see below for responses in-line.
> 
> On 1/29/2012 4:49 AM, zhang.fei3@zte.com.cn wrote:
>>
>> Hi CCAMPers
>>
>> As discussed in the last IETF meeting and mailinglist, the Global_ID
>> should be carried in the signaling messages. One reason is that the
>> judgement of a mis-connectivity defect needs the A1/Z9 nodes to
>> pre-store each other's MEP_ID, whose format is:
>> Gobal_ID+Node_ID+Tunnel_num+LSP_num.
>>
>> Fortunately, there are several drafts related to this topic now,
>>
>> 1.  http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01.
>>    
>> The Globa_ID is incorporated into the ASSOCIATION object in the current
>> version, which guarantees that the association is global unique. Since
>> the ASSOCIATION object is used across different LSPs, just my2cents, the
>> defined format is deficient to handle more scenarios. For example:
>>
>>     (1) Considering a corouted bidirectional LSP, which is not protected
>> by other LSPs through control plane and/or does not share the same
>> resoures with other LSPs.
> 
> 
>> In these cases, the ASSOCIATION object will
>> not be carried in the sigaling messages.
> 
> Why not?  One of the purposes of this draft is to support non-recovery
> uses of the association object.  Note the name of section 2.
> 
> <Fei>
> 
> According to my understanding, the association object is used to
> associate different LSPs. 

I agree that this is the original motivation for the association object.
 But if the need information is already defined for this object, why
define another object that carries the same information.  We certainly
can add some text to the draft to highlight this possibility.

> See the descriptions in section 2:
> "As described below,association is always done based on matching
> either Path state to Path state, or Resv state to Resv state"
> 
> Consider the following scenairos:
> 
>                LSP1
> A-------------------------------------------Z
> 
> Node A is located in AS1 and node Z is located in AS2, when the Path
> message for LSP1 (co-routed bidirectinal LSP) with Extended Association
> Object inserted is initiated at node A, three issues:
> 
> I1: what kind of association type is used here?

the same as you'd use in an associated by directional. Per your draft
this is type 4.  Your draft can make this clear; perhaps by renaming the
type to something along the lines of "LSP identification", and
explicitly covering this case.

> 
> I2: association object is used across different path states, but LSP1
> is not associated with any other LSPS in this case.

Strcikly speaking, for co-routed LSPs the association is per standard
RSVP and the association object is just carrying the LSP identification
information.

> 
> I3: Node A still does know the global ID of node Z
> 

Right, that has always come in the resv.

> If these issues are really existed, the current usage of association object
> should be revised, for example, like this:
> 
> R1: It can be used not to math path state, in other words, it can appear
> only
> in one LSP's path message (no need to be pair)
> 

I think this is allowed, but certainly adding a few words to assoc-ext
to make this explicit is fine.

> R2: It can be used across Path and RESV state, in this way, an
> association object
> can be inserted at node Z in the RESV message, with the global ID of node Z
> 

Again, in the single LSP case, association is being made per standard RSVP.

> R3: If issue 2 is agreeed, a new association type needs to be defined here?
> 
Alternatively, just expand the scope/name of type 4 in your draft.

Lou

> </Fei>
> 
>  
>>
>>     (2) Considering an associated bidirectional LSP, although the
>> ASSOCIATION object is carried in the sigaling messages, the global_ID
>> incorporated in the ASSOCIATION object only
>> indicates the global prefix of the A1 or Z9 nodes. If this LSP is across
>> different domains, I think the current format is also deficient (A1 does
>> not know the gobal ID of Z9 node or Z9 nodes does not know the global ID
>> of A1 ).
> 
> It's not clear to me what problem you're trying to solve.  Can you
> rephrase?
> 
> <fei>
> 
> Similarly with the issue 2 provided above, when LSP1 and LSP2 are bound
> together
> to be an associated bidirectional LSP, the global ID carried in the
> LSP1's and
> LSP2's Path messages are node A's or node Z's, if it is the global ID of
> node A,
> node A still does know the global ID of node Z.
> 
>                LSP1
> A-------------------------------------------Z
>                LSP2
> Hope I clarify it clearly.  :)
> 
> </fei>
> 
> 
> Also keep in mind that multiple association objects have always been
> supported and this ability is not modified by the draft.
> 
> <fei>
> I agree
> </fei>
> 
>>
>> 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01
>>
>> The Global_ID Object and the ICC_Operator_ID Object are defined in this
>> draft,  which describes the procedure of corouted bidirectional LSP
>> (associated bidirectional LSP is not covered in the current version) and
>> requires that the same format( Global_ID or ICC_Operator_ID)is used
>> along the LSP.
> 
> Yes.  This was discussed at the last IETF.  The WG previously had a
> solution to this based on the association object, see rev 00 of the WG
> document.  I removed it from the document based on discussion in Quebec.
> As discussed in Taipei the current rev can still be used to carry the
> ITU-T identifiers (yes, the parts that were in -00 need to be separately
> published to document this.)
> 
> <fei>
> I agree, no problem here
> </fei>
> 
>>
>> 3.
>>
> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01
>>
>>  
>> The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which
>> will appear in the Path/Resv message of corouted bidrectional LSP and
>> only appear in the Path message of associated bidirectional LSP.
>> Furthermore, this draft defined a Connection TLV used to carry the local
>> tunnel number assigned at Z9 nodes in the scenario of corouted
>> bidirectional LSP.
> 
> Is there a question here?
> 
> <fei>
> 
> If what I described in part 1 is reasonable, and the usage of association
> object can be modified to cover these issues, there are no problem here
> also.
> 
> </fei>
> 
> Lou (as contributor)
> 
>>
>>
>> The above materials only provide the rough background.
>>
>>
>> Hope to hear the opinions from the WG that how to carry the Global_ID,
>> then move the work forward.
>>
>>
>> Best regards
>>
>> ;)
>>
>> Fei
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 