Re: [Pce] Remaining BRPC last call comment

["Peng He" <peng.he.2000 at gmail.com>]

I agree with Adrian, the domain-sequence should be indicated
explicitly and kept consistency when passing through.

But I don't understand "each PCE along the path would decide of the
"best next domain" to traverse next" , I suppose the domain-sequence
is kind of 'global optimality' by all means; then how does a PCE
decide  the 'best next domain', how do you define the term 'best', and
it might be 'local optimality' in most times as Adrian's example
indicates.

>   On the other hand, I think it remains crucial to be able to indicate the
>  domain(s) to exclude in the sequence of domains (for diversity or political
>  reasons).

If  the domain-sequence is decided by all means, then it might already
exclude the unwanted domain(s) I guess.


Regards,
Peng

On Mon, Mar 31, 2008 at 5:45 PM, Meral Shirazipour
<meral.shirazipour at polymtl.ca> wrote:
> Hi Adrian,
>   I do not disagree with you that it would be a plus to be able to 'sometimes'
>  indicate the sequence of domains we want the path to go through; however I
>  understood that in most cases, each PCE along the path would decide of the
>  "best next domain" to traverse next.
>
>   On the other hand, I think it remains crucial to be able to indicate the
>  domain(s) to exclude in the sequence of domains (for diversity or political
>  reasons).
>
>  Regards,
>  Meral
>
>
>
>  Selon Adrian Farrel <adrian at olddog.co.uk>:
>
>
>
>  > Hi JP,
>  > Thanks for convergence.
>  >
>  > There is just one remaining issue for discussion.
>  > I've reproduced the thread here, but all the discussion is at the end.
>  >
>  > Cheers,
>  > Adrian
>  >
>  > >>>> Section 5
>  > >>>>
>  > >>>> Is it assumed that PCE(i) knows which domain the requesting
>  > >>>> PCE(i-1) represents?
>  > >>>> The reverse is obviously true because PCE(i-1) must select
>  > >>>> PCE(i) on this basis, but it seems to me that the PCReq could
>  > >>>> useful identify the neighboring (upstream) domain. This would
>  > >>>> be particularly useful in the case of a requesting PCE that
>  > >>>> represents multiple domains since it will allow PCE(i) to know
>  > >>>> which are the BN-en(i) nodes.
>  > >>>>
>  > >>>> Conversely, if PCE(i) has computation capabilities for multiple
>  > >>>> domains, it will need to be told which for domain(i) it should act.
>  > >>>> So we either need protocol extensions (requesting domain,
>  > >>>> computation domain) or we need to be told how to use existing
>  > >>>> protocol fields for this purpose.
>  > >>>>
>  > >>>> Furthermore :-( how although the sequence of domains is known
>  > >>>> (a priori) by the PCC, we need some way to convey the sequence
>  > >>>> in the PCReq so that PCE(i) knows that the next domain in the
>  > >>>> sequence is domain(i+1).
>  > >>>> If this can be achieved by existing protocol mechanism, you need
>  > >>>> to describe the procedures. If it can't be done, we need protocol
>  > >>>> extensions.
>  > >>>
>  > >>> We make the assumption that the sequence of domains is pre-
>  > >>> determined or discovered by some means that is outside of the
>  > >>> scope of this document.
>  > >>> You're right that we do not say that the sequence of PCE is also
>  > >>> predetermined or discovery by some means. Do you want us to
>  > >>> explicitly add this assumption?
>  > >>>
>  > >>> Consider the two following cases:
>  > >>> 1) Inter-area: obvious
>  > >>> 2) Inter-AS: if the sequences of domain and related PCEs are known,
>  > >>> there is no need for protocol extensions except if we want to enforce
>  > >>> the sequence of PCEs, which can be done thanks to the PCE-ID
>  > >>> object defined in
>  > >>> http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-01.txt
>  > >>> We could include the PCE-ID object definition in BRPC and add
>  > >>> some text here.
>  > >>> Thoughts?
>  > >>
>  > >> Well, I have no problems with "the sequence of domains is known a
>  > >> priori." In fact, I strongly support it.
>  > >>
>  > >> However, to whom is this sequence known?
>  > >>
>  > >> Yes, if the ingress PCC or PCE knows the PCEs responsible for each
>  > >> domain, then it could provide a list of such PCEs. But this is more
>  > >> information than is implied in "the sequence of domains". My assumption
>  > >> is that the default position is that PCE(i) will select PCE(i+1).
>  > >
>  > > This is what we referred to as ³discovered by some means² indeed.
>  > >
>  > >> But how does PCE(i) know that the next domain is domain(i+1)? How
>  > >> is the a priori knowledge passed to PCE(i)?
>  > >
>  > > By some means out of the scope of the document.
>  > > Example: inter-area + PCE on the ABR + PCE discovery
>  > > (RFC 5088/5089).
>  > > There are other mechanisms available but out of the scope of this
>  > > document.
>  > >
>  > >> This is important, because knowing the sequence of PCEs is not enough
>  > >> to know the sequence of domains. A PCE may serve more than one
>  > >> domain.
>  >
>  > OK
>  > The difference in our view point is, I think, what we mean by "the series of
>  > domains is known a priori." Let's use ASes as the example, because it is
>  > slightly more complex.
>  > Here comes some ASCII Art (TM)
>  >
>  > <ascii-art>
>  >                 ---------
>  >                | AS-B    |
>  >  ---------     |         |     ---------
>  > | AS-A    |----|         |----| AS-D    |
>  > |         |    |         |    |         |
>  > |   PCC   |----|         |----|  Egress |
>  > |         |     ---------     |         |
>  > |         |       |   |       |         |
>  > |         |     ---------     |         |
>  > |         |----| AS-C    |----|         |
>  > |         |    |         |    |         |
>  > |         |----|         |----|         |
>  >  ---------     |         |     ---------
>  >                |         |
>  >                 ---------
>  > </ascii-art>
>  > Here we have 4 ASes and we want to get from the PCC to the Egress.
>  > The ASes are interconnected as shown.
>  > Let's assume that there are five PCEs. PCE-A, PCE-B, PCE-C and PCE-D have
>  > obvious scope.
>  > PCE-E is special, it is capable of computing paths in AS-B and AS-C.
>  >
>  > So, in my book, "the series of domains is known a priori" means that it is
>  > known before path computation starts. That means, either the PCC knows the
>  > series of ASes (say, ABD) or the sequence is known by PCE-A.
>  >
>  > In the former case, we need a way for the PCC to pass that information to
>  > PCE-A. Note that this is not a sequence of PCEs. It is a sequence of
>  > domains.
>  >
>  > Let's suppose that PCE-A now knows the series of domains, ABD. Let us assume
>  > that it selects PCE-B as the next PCE in the series. How does it communicate
>  > to PCE-B that the series of domains is ABD and not ABCD? One possible way to
>  > do this, would be to signal the series of PCEs (PCE-A, PCE-B, PCE-D). But
>  > that has some implication of a one-to-one relationship between PCEs and
>  > domains.
>  >
>  > So suppose PCE-A selects PCE-E as the next PCE in the series. How does PCE-E
>  > know the pre-determined series of domains? How does it know that it has been
>  > asked to find a path across AS-B and not AS-C? Do we suppose that this a
>  > priori knowledge permeates the ether? Or is it passed along with the
>  > request? Note that the sequence of PCEs PCE-A, PCE-E, PCE-D does not help
>  > because we could still select a path through domains ABCD.
>  >
>  > So, I think that PCEP needs to be able to indicate the sequence of domains
>  > that should be traversed. The additional ability to indicate the sequence of
>  > PCEs is a great supplement.
>  >
>  >
>  > _______________________________________________
>  > Pce mailing list
>  > Pce at ietf.org
>  > https://www.ietf.org/mailman/listinfo/pce
>  >
>  >
>
>
>
>  _______________________________________________
>  Pce mailing list
>  Pce at ietf.org
>  https://www.ietf.org/mailman/listinfo/pce
>
_______________________________________________
Pce mailing list
Pce at ietf.org
https://www.ietf.org/mailman/listinfo/pce