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 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
> >
> > >> 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 further
> > > analysis beyond the scope of this document.
> >
> >_______________________________________________
> >Softwires mailing list
> >Softwires@ietf.org
> >https://www.ietf.org/mailman/listinfo/softwires
>
>