Subject: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 23 Aug 2012 16:20:33 +0000

Dear WG,

We like to request a review from the WG on the changes in version 04 of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version 03. 

The majority of the proposed changes are around the format and how to populate the extended association object as listed below.

Note: Based on the feedbacks received so far, changes for items 4 and 5 below will be reverted.

1. Association-ID:
It was not clear from reading the version 03 of the draft how this field is populated in the extended association object. New version 04 proposes to populate this field from the locally provisioned value. As this value is identically provisioned on both ends, it provides a field to tie the two (forward and reverse) LSPs on end-points.

2. IPv4 association source:
New version 04 adds a tie breaker rule for double sided provisioned LSPs.

3. Global association source:
New version clarifies the usage for this field siting information from RFC6370 and other mentioned drafts. No new rule added.

4. Association Type and Association Flags:
New version proposes to use one association Type for single and double sided provisioned bi-directional LSPs and define association flags for them. These changes will be reverted as they are not necessary. There will not be Association Flags field in the next version.

5. Support for co-routed LSPs:
New version 04 defines a flag and handling for co-routed LSPs. Based on the WG feedback received, these changes will be reverted.

6. Extended Association ID (Address):
New version 04 proposes to use an IP address as extended association ID (address) as an additional identifier. Previous version 03 defines a variable length field but did not mention what parameters can be added there.
A tie breaker rule is defined for double sided provisioned value.

7. Path Protection object:
Version 03 of the draft vaguely mentioned and assumed of using protection object for path protection. New version 04 adds some texts to clarify it, no new rule is added.

8. Auto-tunnel mesh:
New version 04 adds a section to elaborate on a use case for auto-tunnel mesh. This is added as an FYI and can be removed if WG thinks so.

9. Clarification for Inter-AS LSPs:
I believe there was an email exchange between Lou and Fei to clarify the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in version-04 to address this. Please review the added text.

Please advise us on above changes. Based on the consensus, we will update the draft accordingly.

Thanks,
Rakesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 10:53 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

A new version of I-D, draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
has been successfully submitted by Rakesh Gandhi and posted to the IETF repository.

Filename:	 draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
Revision:	 04
Title:		 RSVP-TE Extensions for Associated Bidirectional LSPs
Creation date:	 2012-08-15
WG ID:		 ccamp
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
Htmlized:        http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04

Abstract:
   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654],
   describes that MPLS-TP MUST support associated bidirectional point-
   to-point LSPs.

   This document provides a method to bind two unidirectional Label
   Switched Paths (LSPs) into an associated bidirectional LSP.  The
   association is achieved by defining the new Association Type in the
   Extended ASSOCIATION object.

The IETF Secretariat

---

From: John E Drake <[email-masked]>
Date: Thu, 23 Aug 2012 10:15:34 -0700

This sounds extremely reasonable.

Yours irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Rakesh Gandhi (rgandhi)
> Sent: Thursday, August 23, 2012 9:21 AM
> To: [email-masked]
> Subject: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-
> tp-rsvpte-ext-associated-lsp-04.txt
> 
> Dear WG,
> 
> We like to request a review from the WG on the changes in version 04 of
> the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to
> version 03.
> 
> The majority of the proposed changes are around the format and how to
> populate the extended association object as listed below.
> 
> It was not clear from reading the version 03 of the draft how this
> field is populated in the extended association object. New version 04
> proposes to populate this field from the locally provisioned value. As
> this value is identically provisioned on both ends, it provides a field
> to tie the two (forward and reverse) LSPs on end-points.
> 
> New version clarifies the usage for this field siting information from
> RFC6370 and other mentioned drafts. No new rule added.
> 
> New version proposes to use one association Type for single and double
> sided provisioned bi-directional LSPs and define association flags for
> them. These changes will be reverted as they are not necessary. There
> will not be Association Flags field in the next version.
> 
> New version 04 defines a flag and handling for co-routed LSPs. Based on
> the WG feedback received, these changes will be reverted.
> 
> New version 04 proposes to use an IP address as extended association ID
> (address) as an additional identifier. Previous version 03 defines a
> variable length field but did not mention what parameters can be added
> there.
> Version 03 of the draft vaguely mentioned and assumed of using
> protection object for path protection. New version 04 adds some texts
> to clarify it, no new rule is added.
> 
> 8. Auto-tunnel mesh:
> New version 04 adds a section to elaborate on a use case for auto-
> tunnel mesh. This is added as an FYI and can be removed if WG thinks
> so.
> 
> I believe there was an email exchange between Lou and Fei to clarify
> the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-
> tunnel-num. A section is added in version-04 to address this. Please
> review the added text.
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 Aug 2012 13:55:28 -0400

Rakesh,

Speaking as a WG participant, and ignoring changes 4 and 5 as you plan
to revert these:

> New version clarifies the usage for this field siting information from RFC6370 and other mentioned drafts. No new rule added.

[4 and 5 removed form mail as to be reverted]

> A tie breaker rule is defined for double sided provisioned value.

Assuming changes 1, 2, and 6, how is uniqueness (of the association ID
field) guaranteed?

> Version 03 of the draft vaguely mentioned and assumed of using protection object for path protection. New version 04 adds some texts to clarify it, no new rule is added.

I think providing informative text on interactions of this document with
the various defined recovery (4872 and 4872) and reroute (4090)
mechanisms is a really good idea.  That said, I found this section a bit
opaque.  Ignoring the wordsmithing, what specific points are you trying
to make?

> New version 04 adds a section to elaborate on a use case for auto-tunnel mesh. This is added as an FYI and can be removed if WG thinks so.

How is the association id field value selected in this case?

> I believe there was an email exchange between Lou and Fei to clarify the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in version-04 to address th…

Well I (as chair) had asked in Vancouver that the authors of
rsvpte-ext-tunnel-num propose some language *on the list* that would
merge the functionality defined in that document into the WG document.
The mailing list discussion concluded with Fei stating that he want to
keep the drafts separate, which certainly is his call (as one is an
individual draft).  So to be clear, I have not requested any references
to rsvpte-ext-tunnel-num in the WG draft.

This section does highlight the issue of how remote global_ID can be
learned in the interdomain case.  I think the stated solution doesn't
work with your current assignment approach, e.g., consider the case when
the lower IP address is the egress of the initial LSP...

Lou

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 24 Aug 2012 18:31:46 +0000

Hi Lou,

Thanks for your review. Please see inline..<RG>..

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, August 24, 2012 1:55 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,

Speaking as a WG participant, and ignoring changes 4 and 5 as you plan to revert these:

<RG> 1, 2 and 6 <association-id, source, destination> together uniquely represent a bidirectional LSPs in a network. In this proposal association ID can be shared by multiple tunnels on the same source node.

> Version 03 of the draft vaguely mentioned and assumed of using protection object for path protection. New version 04 adds some texts to clarify it, no new rule is added.

I think providing informative text on interactions of this document with the various defined recovery (4872 and 4872) and reroute (4090) mechanisms is a really good idea.  That said, I found this section a bit opaque.  Ignoring the wordsmithing, what specific points are you trying to make?

<RG> It just highlights that for a bi-directional tunnel, there can be a working bidirectional LSPs and protecting bidirectional LSPs. That's all.

<RG> Proposal allows that single association-id can be provisioned for a mesh-group. So when a node initiates multiple auto-tunnels in a mesh-group, as per previous definition, a tunnel can be uniquely identified with <association-id, source, destination>, i.e. extended association object.

> I believe there was an email exchange between Lou and Fei to clarify the relationship with draft I-D, draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in version-04 to address th…

Well I (as chair) had asked in Vancouver that the authors of rsvpte-ext-tunnel-num propose some language *on the list* that would merge the functionality defined in that document into the WG document.
The mailing list discussion concluded with Fei stating that he want to keep the drafts separate, which certainly is his call (as one is an individual draft).  So to be clear, I have not requested any references to rsvpte-ext-tunnel-num in the WG draft.

This section does highlight the issue of how remote global_ID can be learned in the interdomain case.  I think the stated solution doesn't work with your current assignment approach, e.g., consider the case when the lower IP address is the egress of the initial LSP...

<RG> I will let Fei address this comment.

Thanks,
Rakesh

Lou

> Subject: New Version Notification for 
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> 
> A new version of I-D, 
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 24 Aug 2012 18:58:58 +0000

Thank you John for the review.

Regards,
Rakesh

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, August 23, 2012 1:16 PM
To: Rakesh Gandhi (rgandhi); [email-masked]
Subject: RE: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Yours irrespectively,

John

> We like to request a review from the WG on the changes in version 04 
> of the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to 
> version 03.
> 
> this value is identically provisioned on both ends, it provides a 
> field to tie the two (forward and reverse) LSPs on end-points.
> 
> New version 04 defines a flag and handling for co-routed LSPs. Based 
> on the WG feedback received, these changes will be reverted.
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 24 Aug 2012 16:40:36 -0400

Rakesh,

See below.

> <RG> 1, 2 and 6 <association-id, source, destination> together uniquely represent a bidirectional LSPs in a network. In this proposal association ID can be shared by multiple tunnels on the same so…

Sure, but who picks the association-id such that uniqueness is assured
in the double sided provisioning case?

If assuming this is always provisioned, then how does the provisioning
entity, which may be one or more people at a CLI, pick the
association-id such that it is unique across the tuple <association-id,
ingress, egress>?  (neither a single provision device nor polling the
ingress and egress are really reasonable solutions.)

Wouldn't it be better for the Association Source and Association ID to
be administratively set? e.g., to the IP address and value selected by
the provisioning source. (Extended Association ID could also be used if
desired, but I'm not sure it really adds value.)

> <RG> It just highlights that for a bi-directional tunnel, there can be a working bidirectional LSPs and protecting bidirectional LSPs. That's all.

I think the proposed text is really confusing and doesn't cover the full
scope (in particular 4872 is about recovery which is both protection and
restoration, it doesn't cover 4873 or 4090). Can you propose (one the
list) some alternate text?

> <RG> Proposal allows that single association-id can be provisioned for a mesh-group. 
I don't think you have text that supports this.  The closest you come is:
   A node provisioned to
   build a mesh of associated bidirectional LSPs may use identical
   association ID for the given mesh-group member peers.

which doesn't say that the "identical association ID" MUST be provisioned.

Lou

>> So when a node initiates multiple auto-tunnels in a mesh-group, as per previous definition, a tunnel can be uniquely identified with <association-id, source, destination>, i.e. extended association object.
>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 24 Aug 2012 21:18:51 +0000

Hi Lou,

Please see inline..<RG2>..

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, August 24, 2012 4:41 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,

See below.

On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote:
> Subject: Re: [CCAMP] Review Request For Changes in 

Sure, but who picks the association-id such that uniqueness is assured in the double sided provisioning case?

If assuming this is always provisioned, then how does the provisioning entity, which may be one or more people at a CLI, pick the association-id such that it is unique across the tuple <association-id, ingress, egress>?  (neither a single provision device nor polling the ingress and egress are really reasonable solutions.)

Wouldn't it be better for the Association Source and Association ID to be administratively set? e.g., to the IP address and value selected by the provisioning source. (Extended Association ID could also be used if desired, but I'm not sure it really adds value.)

<RG2> Sure, association-id and association-source can be set administratively or by any other means (we can reword the draft). Idea here is that for double sided provisioned LSPs, they need to have the same values, so both sides can glue the matching LSPs.

> <RG> It just highlights that for a bi-directional tunnel, there can be a working bidirectional LSPs and protecting bidirectional LSPs. That's all.

I think the proposed text is really confusing and doesn't cover the full scope (in particular 4872 is about recovery which is both protection and restoration, it doesn't cover 4873 or 4090). Can you propose (one the
list) some alternate text?

<RG2> Idea here is that there are multiple bidirectional LSPs for a tunnel for different LSP roles. We could remove the LSP type as primary and secondary reference from the text, and just state LSPs for different roles.

<RG2> Yes, we can clarify this.

Thanks,
Rakesh

Lou

---

From: [email-masked]
Date: Sun, 26 Aug 2012 11:43:41 +0800

Hi Lou, 

Thanks for your detailed review, snipped the others, see inline with <fei>

<Fei> Sure, this part is also informational and there is no new mechanism 
introduced here. :)

<Fei> For the singled sided provisioning model, the initial LSP source 
address (Association Source)and global_ID are pushed into the EA objects, 
so the ingress can learn the global ID of the peer node by the defined 
Association Type "LSP Identifiers" which is carried in the Path message 
and back in the Resv messages.

For the doubled sided provisioning model, since the lower IP address 
(Association Source) wins the tie breaker, the Association object with 
Association Type "LSP Identifiers" can be pushed into the Path message by 
the lower IP address initial LSP can carry back the global_ID of the 
higher IP address in the Resv message.

In other words, the Association object with Association Tyep "LSP 
Identifiers" are always pushed by the Association Source into the Path 
message can carried back in the Resv message with the peer node's 
global_ID in both provisioning model if necessary.

Do you think the currently description needs more clarification words?

Thanks

Fei

Lou Berger <[email-masked]> 
发件人:  [email-masked]
2012-08-25 01:55

收件人
"Rakesh Gandhi (rgandhi)" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [CCAMP] Review Request For Changes in 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,

> We like to request a review from the WG on the changes in version 04 of 
the draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp compared to version 
03. 
> It was not clear from reading the version 03 of the draft how this field 
is populated in the extended association object. New version 04 proposes 
to populate this field from the locally provisioned value. As this value 
is identically provisioned on both ends, it provides a field to tie the 
two (forward and reverse) LSPs on end-points.

> Version 03 of the draft vaguely mentioned and assumed of using 
protection object for path protection. New version 04 adds some texts to 
clarify it, no new rule is added.

> 8. Auto-tunnel mesh:
> New version 04 adds a section to elaborate on a use case for auto-tunnel 
mesh. This is added as an FYI and can be removed if WG thinks so.

> I believe there was an email exchange between Lou and Fei to clarify the 
relationship with draft I-D, 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num. A section is added in 
version-04 to address this. Please review the added text.

Lou

> URL:             
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

> Status:          
http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp

> Htmlized:        
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04

> Diff:            
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04

---

From: Lou Berger <[email-masked]>
Date: Sun, 26 Aug 2012 10:30:33 -0400

Rakesh,
	See below (using normal reply notation)...

> <RG2> Sure, association-id and association-source can be set administratively or by any other means (we can reword the draft). Idea here is that for double sided provisioned LSPs, they need to have…

I think we agree on the objective, now we just need some words to
achieve it. (I.e., whatever text is specified, it must support a viable
approach to ensuring uniqueness, i.e., no collision.)  So, care to try
again on proposing such language?

> <RG2> Idea here is that there are multiple bidirectional LSPs for a tunnel for different LSP roles. We could remove the LSP type as primary and secondary reference from the text, and just state LSP…

Again, I think the issue is with the proposed language.

> <RG2> Yes, we can clarify this.

Great!

Lou

---

From: Lou Berger <[email-masked]>
Date: Sun, 26 Aug 2012 15:45:41 -0400

On 8/25/2012 11:43 PM, [email-masked] wrote:
> <Fei> Sure, this part is also informational and there is no new
> mechanism introduced here. :)

Given the recent discussion (on co-routed) I don't think the reference
makes any sense given the scope of rsvpte-ext-tunnel-num propose is
co-routed bidirectional which is currently 100% out of scope of this
document.

> address (Association Source)and global_ID are pushed into the EA
> objects, so the ingress can learn the global ID of the peer node by the
> defined Association Type "LSP Identifiers" which is carried in the Path
> message and back in the Resv messages.

this implies a rule of the lower IP address always signaling its LSP
first.  Seems a bit arbitrary to me, and isn't reflected in the current
text.  How about just following the administrative approach being
discussed with Rakesh in the other thread on the same topic?

Lou

> Association Type "LSP Identifiers" can be pushed into the Path message
> by the lower IP address initial LSP can carry back the global_ID of the
> *Lou Berger <[email-masked]>*
>> New version 04 proposes to use an IP address as extended association
> ID (address) as an additional identifier. Previous version 03 defines a
>> New version 04 adds a section to elaborate on a use case for
> auto-tunnel mesh. This is added as an FYI and can be removed if WG
> thinks so.
>>
> 
> the relationship with draft I-D,
>> Filename:                
>  draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp
>> Revision:                  04

---

From: [email-masked]
Date: Mon, 27 Aug 2012 09:03:18 +0800

Lou, see response lined with <fei1>

Thanks

Fei

2012-08-27 03:45

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>, "Rakesh Gandhi (rgandhi)" 
<[email-masked]>
主题
Re: [CCAMP] Review Request For Changes in 
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

<fei1>Ok, I agree with your statement, and the text just wants to show 
that
the same procedure defined in rsvpte-ext-tunnel-num (which is scoped to 
corouted bidirectional LSP) can be used here also if necessary. 

Do you have any advice how to organize this paragraph?

(1)Remove the cited reference and delete this paragraph, just ignore this
issue.

(2)Remove the cited reference and keep this paragraph (with revision)

If it is (2), can you help give some words?

Or other schemes?

<fei1>The Association Source could be the lower IP address or the higher 
IP address in
single sided provisioning model, which is depending on the touch point and
different from the double sided (the lower IP address always wins). The 
administrative
approach can integrate both models, will be a good idea.

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Aug 2012 14:30:32 -0400

Fei,
	The problem only exists in the double sided provisioing case, so no
need to complicate the single sided provisioning case.

Lou

On 8/26/2012 9:03 PM, [email-masked] wrote:
> The administrative

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 27 Aug 2012 21:16:41 +0000

Thanks Lou.

Let me propose revised texts for section 3.2.6 [item 7], 3.2.7 [item 8] and 4.1 [items 1,2,3,6].	

Regards,
Rakesh

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Sunday, August 26, 2012 10:31 AM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,

On 8/24/2012 5:18 PM, Rakesh Gandhi (rgandhi) wrote:
> association-id such that it is unique across the tuple 
> <association-id, ingress, egress>?  (neither a single provision device 
> nor polling the ingress and egress are really reasonable solutions.)
> 
> the provisioning source. (Extended Association ID could also be used 
> if desired, but I'm not sure it really adds value.)
> 

I think we agree on the objective, now we just need some words to achieve it. (I.e., whatever text is specified, it must support a viable approach to ensuring uniqueness, i.e., no collision.)  So, care to try again on proposing such language?

> I think the proposed text is really confusing and doesn't cover the 
> full scope (in particular 4872 is about recovery which is both 
> protection and restoration, it doesn't cover 4873 or 4090). Can you 
> propose (one the

Great!

Lou

---

From: [email-masked]
Date: Tue, 28 Aug 2012 10:20:36 +0800

Thank you lou

How about changing the descriptions in paragraph 3.2.8

   In some scenarios, a node that is the association source MAY need to
   learn about the Global_ID [RFC6370] of the peer node, which can be
   done by inserting the ASSOCIATION object with Association Type "LSP
   identifiers" in the outgoing Path message and being carried back in
   the Resv message, as defined in [I-D, draft-zhang-ccamp-mpls-tp-
   rsvpte-ext-tunnel-num].

into

   In some scenarios, a node that is the association source MAY need to
   learn about the Global_ID [RFC6370] of the peer node. Although the
   scope of the draft [I-D, 
draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num]
   is limited to the co-routed bidirectional LSP, the defined procedures 
can
   be reused here also. The ASSOCIATION object with Association Type "LSP
   Identifiers" is inserted in the outgoing Path message at the 
association
   source and carried back in the corresponding Resv message. All the 
fields
   of the ASSOCIATION object except the Association Type in the Path 
message
   can be ignored by the receiver and the Global_ID of the peer node is 
pushed
   into the field of the Global Association Source in the Resv message.

Best regards

Fei

2012-08-28 02:30

收件人
[email-masked]
抄送

Fei,
                 The problem only exists in the double sided provisioing 
case, so no
need to complicate the single sided provisioning case.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Aug 2012 08:46:58 -0400

Fei,

I don't think the text addresses the issue of selection of association
object contents in the case of double sided provisioning.  How about:
- in the case of double sided provisioning *only*
  1. Association Source is set to an address selected by the node that
     originates the association. (which may be a management entity.)
  2. Association ID is a value assigned but the node that originates
     the association.
  3. Global Association Source, when used, is set to the Global_ID of
     the node that originates the association.
  4. Extended Association ID, when used, is selected by the node that
     originates the association.
  -  If either (3) or (4) are used, an Extended ASSOCIATION object
     [assoc-ext] is used.  Otherwise a ASSOCIATION object [rfc4872]
     is used

- while we're at it, in the case of single sided provisioning *only*
(note only #1 differs)
  1. Association Source is set to an address assigned to the node that
     originates the LSP.
  2. Association ID is a value assigned but the node that originates
     the association.
  3. Global Association Source, when used, is set to the Global_ID of
     the node that originates the association.
  4. Extended Association ID, when used, is selected by the node that
     originates the association.
  -  If either (3) or (4) are used, an Extended ASSOCIATION object
     [assoc-ext] is used.  Otherwise a ASSOCIATION object [rfc4872]
     is used

I think the above addresses my point as it can be used to ensure unique
LSP association in all cases.  BTW it also aligns very nicely with the
existing definition of the association objects.

To address what I suspect is your concern, 3.2.8 can then become
something like (feel free to revise):

  3.2.8  MPLS-TP Associated Bidirectional LSP Identifiers

  [RFC6370] defines the LSP associated identifiers based on the
  signaling parameters of each unidirectional LSP. The combination
  of each unidirectional LSP's parameters is used to identify the
  Associated Bidirectional LSP.  Using the mechanisms defined in
  this document, any node that is along the path of both
  unidirectional LSPs can identify which pair of unidirectional LSPs
  support an Associated Bidirectional LSP as well as the signaling
  parameters required by [RFC6370].  Note that the LSP end-points
  will always be the path of both unidirectional LSPs.

Lou

On 8/27/2012 10:20 PM, [email-masked] wrote:
>   Identifiers" is inserted in the outgoing Path message at the association

---

From: [email-masked]
Date: Tue, 28 Aug 2012 22:46:18 +0800

Lou

<fei> Do you mean the assocition source can be neither A1 nor Z9 here?

<Fei> RFC6370 requires A1-global_ID and Z9-global_ID, how to push them
into the Extended ASSOCIATION object without new Association type?
 
Hope your clarification

Thanks

Fei

2012-08-28 20:46

收件人
[email-masked]
抄送

Fei,

Lou

association

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 28 Aug 2012 15:28:23 +0000

Hi Lou,

Please see inline..<RG>..

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 8:47 AM
To: [email-masked]
Cc: [email-masked]; Rakesh Gandhi (rgandhi)
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Fei,

I don't think the text addresses the issue of selection of association object contents in the case of double sided provisioning.  How about:
- in the case of double sided provisioning *only*
  1. Association Source is set to an address selected by the node that
     originates the association. (which may be a management entity.)

<RG> For double sided provisioning, both sides can originate the LSPs independently. In this case, there needs to be a rule for a default behavior on which side becomes the association source and hence the proposal to pick the side with lower IP address for the source. This rule can be overridden by the management entity to designate a side to become an association source.

<RG> As both sides can originate LSPs independently,  it would be useful to have a sentence in the draft to indicate how this is populated. As a tie breaker rule by default higher IP address destination is used and it can be overridden by the management entity.

- while we're at it, in the case of single sided provisioning *only* (note only #1 differs)

I think the above addresses my point as it can be used to ensure unique LSP association in all cases.  BTW it also aligns very nicely with the existing definition of the association objects.

<RG> This sounds good.

Thanks,
Rakesh

To address what I suspect is your concern, 3.2.8 can then become something like (feel free to revise):

Lou

On 8/27/2012 10:20 PM, [email-masked] wrote:
>    is limited to the co-routed bidirectional LSP, the defined 
> procedures can
>    can be ignored by the receiver and the Global_ID of the peer node 
> is pushed
>                 The problem only exists in the double sided 
> provisioing case, so no need to complicate the single sided 
> provisioning case.
> 
> Lou
> 
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Aug 2012 11:44:09 -0400

Fei,

> <fei> Do you mean the assocition source can be neither A1 nor Z9 here?

Yes.  The only requirement is (global) uniqueness.

> into the Extended ASSOCIATION object without new Association type?

Solving this issue, i.e., how to signal Global_ID of an LSP, is
currently not within the scope of this document.

Given it's such a small addition, I as a WG contributor, see no reason
not to broaden the scope of this draft (assuming the WG agrees) to
include such support. Although, I think the title and intro of the
document will need to be updated to reflect this change.  I'm also fine
with keeping out of scope, and solving it elsewhere.

Lou

---

From: [email-masked]
Date: Tue, 28 Aug 2012 23:57:02 +0800

Thank you Lou for your nice interpretation

We will update the paragraph 3.2.8 as you proposed.

Regards

Fei

2012-08-28 23:44

收件人
[email-masked]
抄送

Fei,

Lou

> *Lou Berger <[email-masked]>*
procedures
association

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Aug 2012 12:02:05 -0400

Rakesh,
	See below.

On 8/28/2012 11:28 AM, Rakesh Gandhi (rgandhi) wrote:
>> <RG> For double sided provisioning, both sides can originate the
>> LSPs independently. In this case, there needs to be a rule for a
>> default behavior on which side becomes the association source and
>> hence the proposal to pick the side with lower IP address for the
>> source. 

Why are you assuming that one of the endpoints must be the source?  The
key requirement is that the source+ID(s) must be unique.  This means
that ID(s) must be selected or obtained from the association source.

>> This rule can be overridden by the management entity to
>> designate a side to become an association source.

This is where we disagree.  IMO the entity that selects the ID(s) is the
source and must provide the IP address in which the ID is scoped.

>> <RG> As both sides can originate LSPs independently,  it would be
>> useful to have a sentence in the draft to indicate how this is
>> populated. 

How what is populated, i.e., what is "this"?

>> As a tie breaker rule by default higher IP address
>> destination is used and it can be overridden by the management
>> entity.

I'm sorry, I just don't see how the "higher/lower" IP address scheme
provides uniqueness WRT the ID(s).  You previously said that the entity
that provisions the LSP selects the ID.  In this case it should also
provide the IP address to ensure the object is unique.

What am I missing?

Thanks,
Lou

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 28 Aug 2012 16:26:08 +0000

Hi Lou,

Please see inline..<RG2>.

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 12:02 PM
To: Rakesh Gandhi (rgandhi)
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

Rakesh,
	See below.

On 8/28/2012 11:28 AM, Rakesh Gandhi (rgandhi) wrote:
>> <RG> For double sided provisioning, both sides can originate the LSPs 
>> independently. In this case, there needs to be a rule for a default 
>> behavior on which side becomes the association source and hence the 
>> proposal to pick the side with lower IP address for the source.

Why are you assuming that one of the endpoints must be the source?  The key requirement is that the source+ID(s) must be unique.  This means that ID(s) must be selected or obtained from the association source.

<RG2> I saw your reply to Fei. So ok, association-source is not necessarily a router source address.  

>> This rule can be overridden by the management entity to designate a 
>> side to become an association source.

This is where we disagree.  IMO the entity that selects the ID(s) is the source and must provide the IP address in which the ID is scoped.

<RG2> I see, so association source and ID must be given to a node.

<RG2> Extended association ID.

>> As a tie breaker rule by default higher IP address destination is 
>> used and it can be overridden by the management entity.

I'm sorry, I just don't see how the "higher/lower" IP address scheme provides uniqueness WRT the ID(s).  You previously said that the entity that provisions the LSP selects the ID.  In this case it should also provide the IP address to ensure the object is unique.

<RG2> I see now what you are saying. So identical values for <Association-ID + Source + Ext-ID> must be given to nodes on both sides of the LSPs. It is not tied to the LSP source/destination.

Thanks,
Rakesh

What am I missing?

Thanks,
Lou