Subject: [Softwires] BGP TE attr last call by softwires WG

From: Adrian Farrel <[email-masked]>
Date: Wed, 13 Aug 2008 10:02:08 +0100

[Forwarding to the correct CCAMP mailing address]

From: David Ward <[email-masked]> 
To: David Ward <[email-masked]>, 
Alain Durand <[email-masked]>, [email-masked] 
Sent: Tue Aug 12 23:48 
Subject: BGP TE attr last call by softwires WG 

The softwire WG has LC'ed 

http://www.ietf.org/internet-drafts/draft-ietf-softwire-bgp-te- 
attribute-01.txt 

We will keep open an additional two-week period for wider review 
before moving forward in the publication process. Please have any 
comments to the authors and softwires WG by Aug 26, 2008. 

-DWard, Alain Durand 

bcc: [email-masked], [email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked] 
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 21 Aug 2008 10:53:59 +0100

Hi,

> http://www.ietf.org/internet-drafts/draft-ietf-softwire-
> bgp-te-attribute-01.txt 
>
> We will keep open an additional two-week period for wider
> review before moving forward in the publication process. 
> Please have any comments to the authors and softwires WG 
> by Aug 26, 2008. 

I have no objection to the basic idea of distributing TE
information about CE-PE links especially for use in VPNs. 
But I am worried by one aspect of the document. Hopefully
this is just an editorial issue.

The last call in Softwires appears to have generated some
discussion about aggregation, and this led to the addition 
of section 4.

| 4. Implication on aggregation
|
|    Routes that carry the Traffic Engineering Attribute 
|    have additional semantics that could affect traffic 
|    forwarding behavior. Therefore, such routes SHALL NOT 
|    be aggregated unless they share identical Traffic
|    Engineering Attributes.

As far as it goes, this paragraph is great. It says "do not
perform route aggregation unless it is sensible to do so."

But it says nothing about TE aggregation.

Notwithstanding the TE attribute is non-transitive, there 
is the potential for an implementation to believe that it
should provide some form of TE aggregation.

Consider two cases:

1. A CE is attached by parallel links to a single PE

   Suppose the links have the same switching types, but 
   different bandwidths. Link-a has plenty of bandwidth
   available with an MTU size of x. Link-b has not much
   bandwidth available with an MTU size of y > x.

   Normally, we would expect the PE to advertise a single
   piece of reachability information for the CE leaving
   the actual choice of links to be made by the PE.

   What would the PE advertise in this case?
   - It cannot aggregate the TE information because that
     would imply that there was lots of bandwidth at the 
     larger MTU size.
   - It could include duplicate Switching Capability
     Descriptors, but that would need some clarification as
     duplicate descriptors are intended for different 
     switching caps in the IGP RFCs.
   - It could advertise two pieces of reachability
     information, but that would be a change to how the
     implementation currently works.

2. There is more than one AS

   Consider

     CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2

   PE2 advertises reachability to CE2 and includes TE 
   information. The TE attribute is non-transitive so it is
   not just passed on, but ASBR2 wants to announce
   reachability to CE2 (in the VPN case, we may want to 
   support a multi-AS VPN).

   So ASBR2 can advertise reachability to CE2, but what TE
   parameters does it advertise? The parameters for the 
   link PE2-CE2 are not so helpful because the TE 
   reachability across AS2 may be different. Yet any attempt
   to perform a computation of the TE reachability across
   AS2 (i.e. TE aggregation) is complex and potentially
   unstable. (Of course, if a tunnel is pre-established
   between ASBR2 and PE2 this is a different matter.)

I think that these two different scenarios need attention
in the I-D. 

For the first one, it may just be a matter of indicating 
which approach is to be used.

For the second one, I hope the answer is to recommend 
against any form of TE aggregation. This could easily be
added to section 4, and I would be happy to provide text.
BUT, it will still leave open the question about if and how
TE information is propagated beyond the AS.

Thanks for any clarifications.

Adrian

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 21 Aug 2008 14:10:54 -0700

I agree with Adrian that clarifications on the following scenarios would be
very useful for the implementation and deployment of the I-D. Please see
in-line.

>1. A CE is attached by parallel links to a single PE
<snip>
>     CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2
<snip>

>I think that these two different scenarios need attention
[SC>] 
       
A few days ago, I requested on the list that this I-D should add an
applicability section/scenarios; the above discussions on various scenarios
will also clarify the applicability/usage of this I-D.

>TE information is propagated beyond the AS.
Agree on this view.

-Samita

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 21 Aug 2008 19:04:46 -0400

Hi Adrian

I should talk this over with my Co-authors so for now I won't answer all
your points but I will ask for clarification.

See Inline:

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> 
> Hi,
> 

Interface MTU is part of the PSC TE attributes in the our spec. If the
MTUs are different they should not be aggregated. 
Also In L1VPN (LSC and TDM) networks the Switching type covers Switching
granularity (which is like an MTU).  

I'm trying to understand if you are saying the following text would fix
the problem or you see a larger issue: 
"Therefore, such routes and the corresponding TE information SHALL NOT
be aggregated unless they share identical Traffic Engineering
Attributes".

>    between ASBR2 and PE2 this is a different matter.)

I remember we discussed this aspect originally in the context of L1VPNs
and limited it to a single AS since L1VPNs Basic Mode are limited to a
single AS. I don't recall if we thought this was applicable to a multi
AS solution.  We should clarify this point either way.  

We will get back to you shortly on this point. 
Thanks,
Don

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 22 Aug 2008 00:18:02 +0100

Hello Don,

Thanks for the response.

> MTUs are different they should not be aggregated.

Right.
Aggregation in this case is hard to make representative of reality.

> Also In L1VPN (LSC and TDM) networks the Switching type
> covers Switching granularity (which is like an MTU).

Sure. But I wanted to keep in PSC, because that problem represents a single 
layer network.

> I'm trying to understand if you are saying the following text would
> fix the problem or you see a larger issue:
> "Therefore, such routes and the corresponding TE information
> SHALL NOT be aggregated unless they share identical Traffic
> Engineering Attributes".

The question I am asking is - is the solution to this problem to advertise 
two routes?
(Clearly two is a special case of many.)

I don't believe that in the general (non-TE case) we would consider the case 
of two parallel links between CE and PE as route aggregation. The PE would 
simply advertise reachability (through itself) to the CE.

Hence my question below.

>> 2. There is more than one AS
[SNIP]
>I remember we discussed this aspect originally in the context of
>L1VPNs and limited it to a single AS since L1VPNs Basic Mode
>are limited to a single AS. I don't recall if we thought this was
>applicable to a multi-AS solution.
>
>We should clarify this point either way.

Thanks.
I guess:
- if applicable, how?
- if not applicable, how prevent?

Cheers,
Adrian

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 25 Aug 2008 11:14:15 -0700

Adrian,

> Right. Aggregation in this case is hard to make representative of reality.
> 
> two routes?  (Clearly two is a special case of many.)
> 

Let's put the general (non-TE) case aside, and focus on the L1VPN
scenario. 

According to the bgp-auto-discovery and l1vpn-basic-mode drafts in
the context of L1VPN what is advertised in the BGP auto-discovery
information is the information about *ports*.  Therefore, in the
context of L1VPN TE information advertisements are associated with
individual *ports*, not with a particular CE.  Which means that if
a CE is connected to a PE by N ports, then the BGP auto-discovery
information has to advertise all these N ports, and associated with
each such advertisement may be the TE information.

> >>      implementation currently works.

The answer to your question is that if the implementation follows
the spec, it would advertise information about *ports*.  So, if a
CE has two ports that connect it to a PE, then the PE originates
two L1VPN advertisements, one per port, each with its own TE
attribute.
  
Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 26 Aug 2008 05:54:19 -0700

Adrian,

>      implementation currently works.

I already answered this in my other e-mail yesterday.

> TE information is propagated beyond the AS.

For the second one the answer is in rfc5251:

   Consideration of inter-AS and inter-provider L1VPNs requires further
   analysis beyond the scope of this document.

Yakov.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2008 11:46:26 +0100

Hi Yakov,

You have answered my first question, within the limited scope of basic mode, 
single-AS L1VPN autodiscovery, perfectly. I hope no-one would disagree with 
your interpretation.

This is good, and I support the use of this draft in that limited scenario, 
and I suspect that the concept is extensible to any port-based VPN.

Will you be adding to the draft to say that this is the full extent of the 
applicability of this draft (perhaps using RFC 2119 language)?

If not, then I'm afraid that my question stands. What will happen in the 
case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE 
links?

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2008 11:51:45 +0100

Hi again Yakov,

Thanks also for the reply to my second question.

Your answer seems to imply that the applicability of your work is strictly 
limited to L1VPNs.

If this is the case, we can easily close this discussion by adding text to 
the Abstract and Introduction such as:

  The scope and applicability of this protocol extension is
  currently limited to single-AS deployment scenarios of the
  basic mode of L1VPNs. Further applications are for
  future study, but these mechanisms SHOULD NOT be
  used in any attempt to support TE aggregation.

Cheers,
Adrian

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Aug 2008 09:30:25 -0400

Why "SHOULD NOT" rather than "MUST NOT"?

Lou

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 27 Aug 2008 06:50:28 -0700

Lou,

> Why "SHOULD NOT" rather than "MUST NOT"?

It is already there (Section 4):

   Routes that carry the Traffic Engineering Attribute have additional
   semantics that could affect traffic forwarding behavior. Therefore,
   such routes SHALL NOT be aggregated unless they share identical
   Traffic Engineering Attributes.

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Aug 2008 10:29:15 -0400

If you drop the "unless they share identical Traffic Engineering 
Attributes" then we have alignment.

Lou

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 27 Aug 2008 09:02:19 -0700

Lou,

> Attributes" then we have alignment.

If they do share identical TE attributes, then there is no
problem  to aggregate such routes. So, the current text is correct.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 27 Aug 2008 09:05:40 -0700

Adrian,

> case where BGP is used to advertise TE capabilities on non-(L1)VPN CE-PE 

To address this I would propose to add the following to the Abstract
and Introduction:

    The scope and applicability of this protocol extension
    currently excludes its use for non-VPN deployment scenarios.

Yakov.

-

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Aug 2008 14:40:14 -0400

>problem  to aggregate such routes. So, the current text is correct.

I think you need some additional semantic and aggregation function 
definition if you want to aggregate. (For example: Does the TE 
aggregate represent the resources available to *each* route or to 
*all* the routes?  If the latter, what's the distribution function?)

Also I think some discussion on impact on scaling is 
warranted.  (consider the case where each <PPI, CPI> tuple from a PE 
now needs it's own advisement due to dissimilar TE information per port.)

Lou

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 28 Aug 2008 09:00:05 -0700

Lou,

> *all* the routes?  If the latter, what's the distribution function?)

Constructing BGP TE attribute when aggregating routes with identical 
BGP TE attributes follows procedure of rfc4201.

> now needs it's own advisement due to dissimilar TE information per port.)

As I said before, the granularity of L1VPN auto-discovery advertisements
is a single PE-CE port anyway. So, each <PPI, CPI> tuple from a PE
forms its own route anyway.

And while on the subject of scaling, please keep in mind that BGP
only stores L1VPN routes on PEs that have sites of that VPN connected
to them, and on an RR if used, but *not* on any of the P routers. In
contrast, rfc5252 (OSPF for L1VPN autodiscovery) results in storing
*all VPN TE information for all the VPNs* on *all* the IGP nodes, both P
and PE. So, clearly BGP-based approach scales better than OSPF-based
approach.

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Aug 2008 14:29:25 -0400

Yakov,
         see below.

>BGP TE attributes follows procedure of rfc4201.

ahh, that wasn't obvious.  Need some specific language to that effect.

>forms its own route anyway.

Sure, but as the doc says more than on NLRI can be included in a 
MP_REACH_NLRI  attribute.

>and PE. So, clearly BGP-based approach scales better than OSPF-based

sure this is made clear in the l1vpn document.  What isn't made clear 
is that, per this document, when TE attributes cannot be aggregated, 
each <PPI, CPI> tuple needs its own MP_REACH_NLRI attribute *and* 
advertisement.

Lou

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 28 Aug 2008 16:47:57 -0700

Lou,

> ahh, that wasn't obvious.  Need some specific language to that effect.

Sure. To make it obvious I'll add the following:

> Sure, but as the doc says more than one NLRI can be included in a 
> MP_REACH_NLRI  attribute.

That does not change the number of routes that PEs and RRs have
to maintain. 

> each <PPI, CPI> tuple needs its own MP_REACH_NLRI attribute *and* 

It would be quite clear if you would read base BGP spec (which is
quoted as a Normative Refence in this document). Quoting Section 
3.1 of BGP spec (rfc4271):

   Multiple routes that have the same path attributes can be advertised
   in a single UPDATE message by including multiple prefixes in the NLRI
   field of the UPDATE message.

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Fri, 29 Aug 2008 09:35:41 -0400

Yakov,
         See below.

>   BGP TE attributes follows procedure of rfc4201.

great.

>That does not change the number of routes that PEs and RRs have

sure, but there's potential for significant impact on number/size of 
advertisements and corresponding processing.

>    field of the UPDATE message.

I believe it is both worthwhile and appropriate to discuss how this 
draft impacts/relates to scaling.  In essence, I'm suggesting a 
similar/parallel to section 5 of rfc 5195.  (which also states things 
that are "quite clear if you would read" BGP specs.)

Lou