Re: BGP TE attr last call by softwires WG

[Yakov Rekhter <yakov@juniper.net>]

Adrian,

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

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.

-
> Thanks,
> Adrian
> 
> >> >> 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.
> >> >
> >> > Interface MTU is part of the PSC TE attributes in the our spec. If the
> >> > 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.
> >
> > 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.
> >
> >> Hence my question below.
> >>
> >> >>    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.
> >
> > 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.
>