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

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

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

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

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)

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

R3: If issue 2 is agreeed, a new association type needs to be defined 
here?

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