Re: [Pce] Remaining BRPC last call comment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pce] Remaining BRPC last call comment
Hi,
Please see inline...
> I agree with Adrian, the domain-sequence should be indicated
> explicitly and kept consistency when passing through.
Again, I believe this is a plus but not a must.
Some PCCs might not even have the capability to come up with such a domain
sequence information.
> 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.
Of course the term "best" would be of local significance, if the PCE making the
decision does not have a global end to end view.
> > 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.
Again I don't agree here. Not all PCCs will be able to come up with the domain
sequence information. However, and mostly for diversity reasons, they will know
the domains/PCEs they want to avoid.
> Regards,
> Peng
>
Regards,
Meral
> 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.