Subject: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

From: "Zhangxian (Xian)" <[email-masked]>
Date: Sat, 15 Feb 2014 01:50:14 +0000

Hi, Dear all, 

   This version differs with the previous one in the following points:

1: Added a section describing how the Path Key resolution works, and it demonstrates that the proposed method can work in both the scenario with PCE, as well as WITHOUT PCE.  
2: Kept the format of RSVP-TE XRO PKS, defined in this draft, the same as that of RFC5521; but the field meaning change slightly; 
3: Added a section discussion topics about PK uniqueness, PK update as well as manageability considerations; 
4: Other changes: editorial changes, added one more contributors;

   Thank all those who have commented and helped improving this draft. We want to move this forward, so please review this version and give us feedback.

Cheers,
Xian (on behalf of all authors)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 2014年2月14日 14:25
To: Dhruv Dhody; Oscar Gonzalez de Dios; Igor Bryskin; Fatai Zhang; Fatai Zhang; Zhangxian (Xian); Zhangxian (Xian); Oscar Gonzalez de Dios; Dhruv Dhody; Igor Bryskin
Subject: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

A new version of I-D, draft-zhang-ccamp-route-exclusion-pathkey-01.txt
has been successfully submitted by Xian Zhang and posted to the
IETF repository.

Name:		draft-zhang-ccamp-route-exclusion-pathkey
Revision:	01
Title:		Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP- TE) to Support Route Exclusion Using Path Key Subobject
Document date:	2014-02-14
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-pathkey-01.txt
Status:         https://datatracker.ietf.org/doc/draft-zhang-ccamp-route-exclusion-pathkey/
Htmlized:       http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-zhang-ccamp-route-exclusion-pathkey-01

Abstract:
   This document extends the Resource ReSerVation Protocol-Traffic
   Engineering (RSVP-TE) eXclude Route Object (XRO) and Explicit
   eXclusion Route Subobject (EXRS) within Explicit Route Object (ERO)
   to support specifying route exclusion requirement using Path Key
   Subobject (PKS).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 20 Feb 2014 17:29:50 +0000

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Friday, February 14, 2014 8:50 PM
To: "[email-masked]" <[email-masked]>
Subject: [CCAMP] FW: New Version Notification for
draft-zhang-ccamp-route-exclusion-pathkey-01.txt

>1: Added a section describing how the Path Key resolution works, and it
>demonstrates that the proposed method can work in both the scenario with
>PCE, as well as WITHOUT PCE.
>

Hi Xian: 

When an ERO expanding node hits exclude Path Key(EXRS), it still needs to
lookup the path associated with the Path Key. So how do you achieve Path
Key lookup WITHOUT PCE?

More comments later,

Thanks

Regards...Zafar

---

From: Cyril Margaria <[email-masked]>
Date: Thu, 20 Feb 2014 21:11:24 +0100

Hi Zafar,

The document follows the same procedure as RFC5553.
PKS resolution using PCE is one possible implementation, the processing
node may use other mechanism (section 3.1 of RFC5553 describes some of
them).

One possible implementation being "The LSR can use the information in the
PKS to index a CPS previously supplied to it by the PCE that originated the
PKS."

This can cover a number of mechanisms including configuration using
management system.

I hope this clarifies the statement.

Best Regards,
Cyril.

On 20 February 2014 18:29, Zafar Ali (zali) <[email-masked]> wrote:

> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 20 Feb 2014 20:25:47 +0000

Hi Cyril-

RFC5553 mentions:

" Resolution of the PKS MAY take any of the following forms or use
     some other technique subject to local policy and network
     implementation.

     o The LSR can use the PCE-ID contained in the PKS to contact the
       identified PCE using PCEP [RFC5440<http://tools.ietf.org/html/rfc5440>] and request that the PKS be
       expanded.

     o The LSR can contact any PCE using PCEP [RFC5440<http://tools.ietf.org/html/rfc5440>] to request that
       the PKS be expanded, relying on cooperation between the PCEs.

     o The LSR can use the information in the PKS to index a CPS
       previously supplied to it by the PCE that originated the PKS."

How any of this justifies the following statement:

"1: Added a section describing how the Path Key resolution works, and it demonstrates that the proposed method can work in both the scenario with PCE, as well as WITHOUT PCE."

Thanks

Regards … Zafar

From: Cyril Margaria <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 20, 2014 3:11 PM
To: zali <[email-masked]<mailto:[email-masked]>>
Cc: "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi Zafar,

The document follows the same procedure as RFC5553.
PKS resolution using PCE is one possible implementation, the processing node may use other mechanism (section 3.1 of RFC5553 describes some of them).

One possible implementation being "The LSR can use the information in the PKS to index a CPS previously supplied to it by the PCE that originated the PKS."

This can cover a number of mechanisms including configuration using management system.

Best Regards,
Cyril.

On 20 February 2014 18:29, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 14, 2014 8:50 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] FW: New Version Notification for

Hi Xian:

More comments later,

Thanks

Regards...Zafar

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Cyril Margaria <[email-masked]>
Date: Thu, 20 Feb 2014 21:49:54 +0100

Hi Zafar:

The point is that to resolve the PKS you MAY use PCEP, or any other method
you see fit.
On the last proposed implementation, you may also replace 'PCE' by 'Node
generating the PKS',

If one see fit to flood the PKS in its IGP or have the management system
configure the PKS information in each PE, it still falls in this statement.

On 20 February 2014 21:25, Zafar Ali (zali) <[email-masked]> wrote:

>        identified PCE using PCEP [RFC5440 <http://tools.ietf.org/html/rfc5440>] and request that the PKS be
>        expanded.
>
>      o The LSR can contact any PCE using PCEP [RFC5440 <http://tools.ietf.org/html/rfc5440>] to request that
>  "1: Added a section describing how the Path Key resolution works, and
> it demonstrates that the proposed method can work in both the scenario
> with PCE, *as well as WITHOUT PCE.*"
>
>  Thanks
>
>  Regards ... Zafar
>
>   From: Cyril Margaria <[email-masked]>
> To: zali <[email-masked]>
> Cc: "Zhangxian (Xian)" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Subject: Re: [CCAMP] FW: New Version Notification for
>  One possible implementation being "The LSR can use the information in
> the PKS to index a CPS previously supplied to it by the PCE that originated
> the PKS."
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 20 Feb 2014 21:13:59 +0000

Hi Cyrill-

This is funny – when we had an out-of-scope statement in draft-ietf-ccamp-lsp-diversity, authors and support of draft-zhang-ccamp-route-exclusion-pathkey starts complaining. Flying in similar statement is all of sudden fine? If you go with flooding PKS, what wrong with flooding RSVP-TE FEC?

Thanks

Regards … Zafar

Date: Thursday, February 20, 2014 3:49 PM

Hi Zafar:

The point is that to resolve the PKS you MAY use PCEP, or any other method you see fit.
On the last proposed implementation, you may also replace 'PCE' by 'Node generating the PKS',

If one see fit to flood the PKS in its IGP or have the management system configure the PKS information in each PE, it still falls in this statement.

On 20 February 2014 21:25, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Cyril-

RFC5553 mentions:

Thanks

Regards … Zafar

Hi Zafar,

Best Regards,
Cyril.

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 14, 2014 8:50 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [CCAMP] FW: New Version Notification for

Hi Xian:

More comments later,

Thanks

Regards...Zafar

---

From: Cyril Margaria <[email-masked]>
Date: Thu, 20 Feb 2014 22:43:00 +0100

Hi Zafar,

The IGP was merely an example.

The document does propose a simple set of extension that works (but are not
restricted to, nor require) with another standard IETF protocol, namely
PCEP.

In order to support LSP diversity, a mechanism to exchange the path used by
a LSP on another node is needed.
I recall that the point of the complain was that without specifying that
protocol the draft cannot be implemented without extra protocol work, and I
believe that draft-ietf-ccamp-lsp-diversity would require new proprietary
protocol to be specified for that purpose.

The approach used in draft-zhang-ccamp-route-exclusion-pathkey does not
require a new proprietary protocol, you may use a PCE and PCEP (colocated
in each PE). This can be implemented using IETF protocols, but its not
limited to them.
draft-zhang-ccamp-route-exclusion-pathkey allows for any other deployment,
with and without PCE.

The document address networks with PCE and without PCE.

Best regards,
Cyril

On 20 February 2014 22:13, Zafar Ali (zali) <[email-masked]> wrote:

>  Hi Cyrill-
>
>  This is funny - when we had an out-of-scope statement
> in draft-ietf-ccamp-lsp-diversity, authors and support
> of draft-zhang-ccamp-route-exclusion-pathkey starts complaining. Flying in
> similar statement is all of sudden fine? If you go with flooding PKS, what
> wrong with flooding RSVP-TE FEC?
>
>  Thanks
>
>  Regards ... Zafar
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 20 Feb 2014 22:45:54 +0000

Date: Thursday, February 20, 2014 4:43 PM

The document does propose a simple set of extension that works (but are not restricted to, nor require) with another standard IETF protocol, namely PCEP.

Can you please qualify this statement? Without PCE (PCEP) this solution does not work.

Thanks

Regards… Zafar

---

From: Cyril Margaria <[email-masked]>
Date: Thu, 20 Feb 2014 23:57:01 +0100

Hi Zafar,

This is described in the section 2.2
"
If it cannot decode the PKS, the error handling procedure defined in
Section 3.1
of [RFC5553] <http://tools.ietf.org/html/rfc5553#section-3.1> is not
changed by this document. This mechanism can work with all the PKS
resolution mechanism, as detailed in [RFC5553] section
3.1<http://tools.ietf.org/html/rfc5553#section-3.1>.
A PCE, co-located or not, may be used to resolve the PKS, but the node
(i.e., a Label Switcher Router(LSR)) can also use the PKS information to
index a Path Segment previously supplied to it by the entity that
originated the PKS, for example the LSR that inserted the PKS in the RRO or
a management system

"

The document could also state :

PKS resolution MAY take any of the forms described in RFC5553 section
3.1. In addition the LSR

can also use the PKS information to index a Path Segment previously
supplied to it by the entity
that originated the PKS. This can be, for example, the LSR that
inserted the PKS in the RRO or a
   management system.

Would that answer your question?

On 20 February 2014 23:45, Zafar Ali (zali) <[email-masked]> wrote:

>  The document does propose a simple set of extension that works (but are
> not restricted to, nor require) with another standard IETF protocol, namely
> PCEP.
>
>
>  Regards... Zafar

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 21 Feb 2014 01:14:31 +0000

Cyril has made it pretty clear. I just want to add that,  the function needed for draft-zhang-ccamp-route-exclusion-pathkey is to resolve path key.  So as long as mechanisms can fulfill this, it works. Definitely using a PCE is a good and obvious example which is included in the draft, but it is NOT the only mechanism, as explained in the updated draft text quoted below.

Regards,
Xian

From: Cyril Margaria [mailto:[email-masked]]
Sent: 2014年2月21日 6:57
To: Zafar Ali (zali)
Cc: Zhangxian (Xian); [email-masked]
Subject: Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi Zafar,
This is described in the section 2.2
"
If it cannot decode the PKS, the error handling procedure defined in Section 3.1 of [RFC5553]<http://tools.ietf.org/html/rfc5553#section-3.1> is not changed by this document. This mechanism can work with all the PKS resolution mechanism, as detailed in [RFC5553] section 3.1<http://tools.ietf.org/html/rfc5553#section-3.1>. A PCE, co-located or not, may be used to resolve the PKS, but the node (i.e., a Label Switcher Router(LSR)) can also use the PKS information to index a Path Segment previously supplied to it by the entity that originated the PKS, for example the LSR that inserted the PKS in the RRO or a management system

"

PKS resolution MAY take any of the forms described in RFC5553 section 3.1. In addition the LSR

can also use the PKS information to index a Path Segment previously supplied to it by the entity
that originated the PKS. This can be, for example, the LSR that inserted the PKS in the RRO or a

   management system.

On 20 February 2014 23:45, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks

Regards… Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 21 Feb 2014 04:20:47 +0000

Hi:

Please see in-line.

Thanks

Regards … Zafar

From: "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 20, 2014 8:14 PM
To: Cyril Margaria <[email-masked]<mailto:[email-masked]>>, zali <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Cyril has made it pretty clear. I just want to add that,  the function needed for draft-zhang-ccamp-route-exclusion-pathkey is to resolve path key.  So as long as mechanisms can fulfill this, it works.

Yes, if you have a proprietary solution, it will work for you. I asked pointers to a standard based solution non-PCE solution where path key resolution is defined – as this is what you are claiming. I am happy if you soften your claim.

Definitely using a PCE is a good and obvious example which is included in the draft, but it is NOT the only mechanism, as explained in the updated draft text quoted below.

Regards,
Xian

From: Cyril Margaria [mailto:[email-masked]]
Sent: 2014年2月21日 6:57
To: Zafar Ali (zali)
Cc: Zhangxian (Xian); [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi Zafar,
This is described in the section 2.2
"
If it cannot decode the PKS, the error handling procedure defined in Section 3.1 of [RFC5553]<http://tools.ietf.org/html/rfc5553#section-3.1> is not changed by this document.
This mechanism can work with all the PKS resolution mechanism, as detailed in [RFC5553] section 3.1<http://tools.ietf.org/html/rfc5553#section-3.1>.

Quoting relevant text from [RFC5553] section 3.1<http://tools.ietf.org/html/rfc5553#section-3.1>..

     Resolution of the PKS MAY take any of the following forms or use
     some other technique subject to local policy and network
     implementation.

     o The LSR can use the information in the PKS to index a CPS
       previously supplied to it by the PCE that originated the PKS.

All these methods are pointing to a PCE based solution.

A PCE, co-located or not, may be used to resolve the PKS, but the node (i.e., a Label Switcher Router(LSR)) can also use the PKS information to index a Path Segment previously supplied to it by the entity that originated the PKS, for example the LSR that inserted the PKS in the RRO or a management system.

How this communication between LSR generating the Path key and LSR seeking Path info happens? If you are only referring to to co-located PCE, then scope comes back to a PCE based solution.

"

   management system.

See above.

Thanks

Regards… Zafar

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 21 Feb 2014 06:13:35 +0000

Is there a particular statement in the draft  you would like to see a change?

Or if you meant my email sent to the list, I did not claim anything like “a standard based solution non-PCE solution where path key resolution is defined”, but rather a PCE is not mandated. However,  if a PCE is used (a solution supported by standards), it can be supported by existing PCEP without protocol extensions, plus additional considerations needed and explained in the latest draft. Does this clarify?

Regards,
Xian

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: 2014年2月21日 12:21
To: Zhangxian (Xian); Cyril Margaria
Cc: [email-masked]
Subject: Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi:

Please see in-line.

Thanks

Regards … Zafar

Regards,
Xian

Hi Zafar,

     implementation.

       expanded.

"

   management system.

See above.

Thanks

Regards… Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 21 Feb 2014 16:17:28 +0000

Hi Xian-

Yes this was triggered by the email. But there is also text in draft that suggest non-PCE scope for the draft. Please clarify the same in the next revision.

I have some other comments, but will send them separately (ASAP).

Thanks

Regards … Zafar

From: "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 21, 2014 1:13 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Cyril Margaria <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Regards,
Xian

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: 2014年2月21日 12:21
To: Zhangxian (Xian); Cyril Margaria
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi:

Please see in-line.

Thanks

Regards … Zafar

Regards,
Xian

Hi Zafar,

     implementation.

       expanded.

"

   management system.

See above.

Thanks

Regards… Zafar

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Sat, 22 Feb 2014 01:27:57 +0000

Hi, Zafar,

      It would be good if you could point out the specific text since currently I do not think we have similar claim in the draft, although we do mention different methods to resolve path key. Looking forward to your comments and it would be good that we can also discuss them during IETF89.

Regards,
Xian

Sent: 2014年2月22日 0:17

Hi Xian-

Thanks

Regards … Zafar

Regards,
Xian

Hi:

Please see in-line.

Thanks

Regards … Zafar

Regards,
Xian

Hi Zafar,

     implementation.

       expanded.

"

   management system.

See above.

Thanks

Regards… Zafar