Re: [Softwires] BGP TE attr last call by softwires WG (2nd question)

[Yakov Rekhter <yakov@juniper.net>]

Lou,

> If you drop the "unless they share identical Traffic Engineering 
> 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.

> 
> Lou
> 
> At 09:50 AM 8/27/2008, Yakov Rekhter wrote:
> >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.
> >
> > >
> > > Lou
> > >
> > > At 06:51 AM 8/27/2008, Adrian Farrel wrote:
> > > >Hi again Yakov,
> > > >
> > > >Thanks also for the reply to my second question.
> > > >
> > > >Your answer seems to imply that the applicability of your work is strict
ly
> > > >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
> > > >
> > > > >> 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.
> > > > >
> > > > > For the second one the answer is in rfc5251:
> > > > >
> > > > >   Consideration of inter-AS and inter-provider L1VPNs requires furthe
r
> > > > >   analysis beyond the scope of this document.
> > > >
> > > >_______________________________________________
> > > >Softwires mailing list
> > > >Softwires@ietf.org
> > > >https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> 
>