Qin,
Please see in-line tagged with Ramon>
El 13/09/2013 9:22, Qin Wu escribió:
Sounds reasonable, I am wondering whether it is sufficient for just
defining one new 'D' flag in the SVEC object? Why 'D' flag was not
defined when RFC5440 was documented.
How do I know computed paths don't have any transit domains in common.
Ramon> there are several things to consider:
*) the D flag is generic, attached to the SVEC tuple, only to convey a
group request constraint. This applies regardless of the actual method
used in computation. We should discuss what are the implications, such
as "are border nodes allowed (corner case)? Of course, a PCC can also
play with inclusion and exclusion provided it has the information on the
interconnection of domains, but I don't see this as a common case.
*) I understood the requirement was scoped to the H-PCE case, where it
is the responsibility of the p-pce to ensure that they are
domain-disjoint when selecting the domain sequence for both paths, and
before segment expansion. How the parent does this I would say it is is
implementation specific (k-shortest disjoint paths, iterative, etc.)
*) I would say that, without more information, a PCE or PCC cannot
simply deduce whether two paths don't have any transit domains in
common, unless this information is conveyed in the path ERO or
attributes. I was thinking that the use of domain objects could be used
http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-03
if the EROs are "tagged" with domain information, it can be deduced
whether both EROs are disjoint or not
Domain diversity is more complicated when computed paths don't even
share ingress domain and egress domain.
Ramon> I guess we agree :o)
Thanks
R.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
