Subject: accepting draft-fedyk-bgp-te-attribute-02.txt as a CCAMP WG document

From: Yakov Rekhter <[email-masked]>
Date: Mon, 01 Oct 2007 12:06:38 -0700

Deborah and Adrian,

On behalf of the authors of draft-fedyk-bgp-te-attribute-02.txt we
would like to propose to accept this draft as a CCAMP WG document.
This draft went through IDR review and we incorporated the comments
in the latest version.

Yakov.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Oct 2007 10:57:57 +0100

Hi Yakov,

Could you explain why we would want to adopt 
draft-fedyk-bgp-te-attribute-03.txt (note that your draft is at revision 03) 
rather than draft-vasseur-ccamp-ce-ce-te-02.txt

The scope of your draft seems to be very open-ended which is quite worrying. 
Perhaps you could help by telling us what the application space is. Your 
introduction section suggests that *an* application is L1VPN, and if that is 
a representative application then your scope is identical to the Vasseur 
draft.

Thanks,
Adrian
----- Original Message ----- 
From: "Yakov Rekhter" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Brungard, Deborah A, ALABS" 
<[email-masked]>; <[email-masked]>
Cc: "Hamid Ould-Brahim" <[email-masked]>; "Don Fedyk" 
<[email-masked]>; <[email-masked]>
Sent: Monday, October 01, 2007 8:06 PM
Subject: accepting draft-fedyk-bgp-te-attribute-02.txt as a CCAMP WG 
document

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 03 Oct 2007 08:19:29 -0700

Adrian,

> rather than draft-vasseur-ccamp-ce-ce-te-02.txt

Are you proposing to adopt draft-vasseur-ccamp-ce-ce-te-02.txt
as a CCAMP WG document ? (simple "yes/no" would suffice).

For one thing, draft-vasseur-ccamp-ce-ce-te-02.txt is unimplementable,
as (quoting from the draft) "The format of the BGP TE attribute will 
be defined in a further revision of this document." In contrast,
draft-fedyk-bgp-te-attribute-03.txt does define the format of the
BGP TE attribute, and is sufficient for implementing the attribute.

> Perhaps you could help by telling us what the application space is. 

As you said below, *an* application of this draft is L1VPN.

> Your introduction section suggests that *an* application is L1VPN, and 
> if that is a representative application then your scope is identical 
> to the Vasseur draft.

Yakov.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Oct 2007 16:41:52 +0100

Yakov,

> as a CCAMP WG document ? (simple "yes/no" would suffice).

I ain't proposing nothin'

> BGP TE attribute, and is sufficient for implementing the attribute.

That is probably a good reason to start with.

> As you said below, *an* application of this draft is L1VPN.

Two questions:

1. Would you be happy if your I-D contained a statement that limit its 
applicability to L1VPNs?

2. Could you conceive of using your I-D to meet the requirements of the 
Vasseur I-D?

Thanks,
Adrian

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 03 Oct 2007 11:51:55 -0700

Adrian,

> 1. Would you be happy if your I-D contained a statement that limit its 

No, as we are not in the business of predicting the future and therefore
not in the business of limiting future applications of the I-D.

> 2. Could you conceive of using your I-D to meet the requirements of the 

In order for me to answer this question I'd like to get a clear
description of the requirements of the Vasseur I-D.

Yakov.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Oct 2007 20:03:39 +0100

> description of the requirements of the Vasseur I-D.

I'm not trying to fight JP's battles for him.
Just trying to find out whether we have two problem spaces or one.

I think the abstract of his I-D is relatively clear:

   This document proposes MP-BGP protocol extension so as to convey
   Traffic Engineering Link characterictics of PE (Provider Edge) - CE
   (Customer Edge) links in order to extend the visibility of the
   Traffic Engineering Database to those links.  This can then be used
   to more efficiently compute CE-to-CE Traffic Engineering Label

A

---

From: JP Vasseur <[email-masked]>
Date: Thu, 4 Oct 2007 19:02:44 -0400

Hi,

Sorry for being late in that thread ...

On Oct 3, 2007, at 3:03 PM, Adrian Farrel wrote:

>>> 2. Could you conceive of using your I-D to meet the requirements  
>>> of the Vasseur I-D?

Yakov, let me know if you need further clarification on the  
application ... sounds
pretty obvious, extend the TED to some PE-CE links where a CE to CE  
TE LSP
is needed. The path computation piece is then very much similar to  
inter-domain
TE (per domain, PCE, ...). My question here is why would you want to  
redefine
TE TLVs where we could simply reuse the TE TLVs carried in IGPs, in  
order to
avoid to redefine TLVs for each TE link characteristic of interest.

Note that the current Abstract:
Abstract

    This document defines a new BGP attribute, Traffic Engineering
    attribute, than enables BGP to carry Traffic Engineering  
information.

is fairly general ... "carry Traffic Engineering information".

Thanks.

JP.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 08 Oct 2007 06:36:13 -0700

JP,

> Sorry for being late in that thread ...

no problem :-)

> TE (per domain, PCE, ...). 

Given the above I could conceive of using the BGP TE attribute, as
defined in draft-fedyk-bgp-te-attribute, to meet the requirements
of your I-D. I hope that answers Adrian's question.

Yakov.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 8 Oct 2007 09:44:12 -0400

Hi Yakov,

> of your I-D. I hope that answers Adrian's question.

Well for the CE to CE application, we need all TE link attribute for  
the PE-CE links, thus our proposal to reuse the TE link attributes  
already defined for the IGPs ?

Thanks.

JP.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 10 Oct 2007 08:10:49 -0700

JP,

> >> inter-domain TE (per domain, PCE, ...).
> >

If there is a CCAMP WG consensus to add additional information to
what is currently specified in the BGP TE attribute the authors of
draft-fedyk-bgp-te-attribute have no problems with adding this info
to what is presently specified in draft-fedyk-bgp-te-attribute.

Yakov.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 11 Oct 2007 09:26:52 +0200

Hi Yakov,

> to what is presently specified in draft-fedyk-bgp-te-attribute.

On the first question, I do not think that there is yet a CCAMP  
consensus
(on both drafts by the way). Furthermore, if we can agree to simply  
reuse
the IGP-TE TLVs to be carried in BGP for the "PE-CE" links we are  
effectively
merging the two IDs, which I had proposed to do since a single draft  
would
then serve both applications and may be future ones. Makes sense ?

Cheers.

JP.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 15 Oct 2007 07:22:03 -0700

JP,

> On the first question, I do not think that there is yet a CCAMP consensus
> (on both drafts by the way). Furthermore, if we can agree to simply reuse
> effectively merging the two IDs, which I had proposed to do since 
> a single draft would then serve both applications and may be future 
> ones. Makes sense ?

No, it does *not* make sense, and here is why. There should be a
separate draft that just defines the BGP TE attribute. Then there
may be one or more other drafts that describe applications that
*use* the BGP TE attribute. Such drafts would just point to the
first draft.

draft-fedyk-bgp-te-attribute is the former - it just defines the
BGP TE attribute. draft-vasseur-ccamp-ce-ce-te-02 is the latter  -
it defines an application that uses the BGP TE attribute. That is
precisely why it does not make any sense to merge the two IDs.

Yet another reason why merging the two IDs does not make sense is
that the BGP TE attribute, as specified in draft-fedyk-bgp-te-attribute,
carries the *GMPLS* TE information, while in your draft you propose
to carry just *MPLS* TE, but *not* GMPLS TE information. Quoting
from your draft:

   This document also defines a new attribute called the
   TE attribute which carries the set of sub-TLVs defined in [RFC3784].
   The format of the BGP TE attribute will be defined in a further
   revision of this document.

Note that rfc3784 is about *MPLS* TE extensions. GMPLS TE extensions
are defined in rfc4203.

Wrt reusing the IGP-TE TLVs, if you look at what is carried in the
BGP TE attribute, as specified in draft-fedyk-bgp-te-attribute, you
should be able to notice that is has precisely the same encoding
as the Interface Switching Capability Descriptor sub-TLV (as defined
in rfc4203). 

Yakov.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 16 Oct 2007 14:02:25 +0200

Hi Yakov,

> *use* the BGP TE attribute. Such drafts would just point to the

Unfortunately, as defined, it is not generic enough to support other
applications.

> it defines an application that uses the BGP TE attribute.

With the major difference being that we proposed to reuse the IGP TE  
TLVs.

We do agree on using BGP to carry TE related data such such "external"
links but why not reusing the IGP TE TLVs instead of defining a new BGP
attribute that will not have the ability to support other  
applications. In particular,
for the CE to CE case, we'll need all the TE link characteristics, as  
defined in
IGP TE.

The approach of having a generic ID defining the protocol details and  
other
applicability statement is fine but I'd rather have a different  
approach for that
generic draft.

> That is

Of course, the same approach can be taken for GMPLS.

> as the Interface Switching Capability Descriptor sub-TLV (as defined

Absolutely, but it does not have the appropriate MPLS TE attributes,
(TE metrics, colors, but also other TLVs defined in other RFCs)
hence my proposal to reuse the MPLS and GMPLS TE extensions
specified for IGP TE.

Thanks.

JP.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 16 Oct 2007 06:55:55 -0700

JP,

> Unfortunately, as defined, it is not generic enough to support other

As I said before (in my e-mail on Oct 10):

> attribute 

In BGP all the information is carried as BGP *attributes* - one can
not take IGP TE TLVs and stuff then "as is" into a BGP Update
message. Which means that carrying any new information in BGP
*requires* to define a new BGP attribute (that is precisely why we
defined a new BGP TE attribute).

Hopefully that answer your question of "why not reusing the IGP TE
TLVs instead of defining a new BGP attribute".

>         that will not have the ability to support other  
> applications. 
> In particular, for the CE to CE case, we'll need all the TE link
> characteristics, as defined in IGP TE.

See my first comment above.

> other applicability statement is fine but I'd rather have a different  
> approach for that generic draft.

So, you withdraw the suggestion you made in your e-mail on Oct 11
to merge draft-fedyk-bgp-te-attribute and your draft.
  
> > That is precisely why it does not make any sense to merge the two IDs.
> >

See my comments above.

With all this in mind let me suggest that if you think BGP needs
to carry more information than what is currently defined in
draft-fedyk-bgp-te-attribute, then after CCAMP WG accepts
draft-fedyk-bgp-te-attribute as a CCAMP WG document you get consensus
of the CCAMP WG that this information is indeed has to be added,
and then we'll add it to the document.

Yakov.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 30 Oct 2007 11:25:07 -0400

Hi Yakov,

Sorry for the delay, I had missed that one - in line.

>    to what is presently specified in draft-fedyk-bgp-te-attribute.

Sure my concern is basically to see an ID redefining all TE related  
attributes
rather than carrying in a new BGP attributes all TLVs that have been  
defined
already for IGPs ?

> to merge draft-fedyk-bgp-te-attribute and your draft.

No no ... I'm proposing to define a BGP attribute carrying the IGP TE  
TLV.

> and then we'll add it to the document.

Well this is the approach of (potentially) redefining everything as  
opposed to
carrying the IGP TE TLV in that new BGP attribute ?

Cheers.

JP.