Sorry for the HTML, but I am hoping this thread can be closed soon.
You're killing me :-)
Hoping you are not red/green colourblind.
Look in line for [DD].
[Snipped to only the points for discussion]
* Sec 5. How Do I Select Between PCEs?
Along with capability, you can also mention the PCE's preference for each
computation scope as carried in the PATH-SCOPE subtlv.
You are going to have to remind me, I'm afraid. Where is the PATH-SCOPE subtlv
defined?
I suppose I was considering that a PCC is only going to choose a PCE in its own
domain, but I can add a note.
[DD] Its in RFC5088, 5089, the idea being PCC should select the PCE in its own
domain which matches with the path computation scope (inter-area, inter-AS,
inter-layer) along with the capability.
Ah, ah, ah! I was busy thinking this was a PCEP sub-tlv.
OLD:
When more then one PCE is discovered or configured, a PCC will need
to select which PCE to use. It may make this decision on any
arbitrary algorithm (for example, first-listed, or round-robin), but
it may also be the case that different PCEs have different
capabilities, in which case the PCC will want to select the PCE most
likely to be able to satisfy any one request. The first requirement,
of course, is that the PCE can compute paths for the relevant domain.
NEW:
When more than one PCE is discovered or configured, a PCC will need
to select which PCE to use. It may make this decision on any
arbitrary algorithm (for example, first-listed, or round-robin), but
it may also be the case that different PCEs have different
capabilities and path computation scope, in which case the PCC will
want to select the PCE most likely to be able to satisfy any one request.
The first requirement, of course, is that the PCE can compute paths for
the relevant domain.
Yeah, OK for that. It duplicates the final sentence I added to this paragraph,
but it does no harm.
* Sec 20. Comparison of Stateless and Stateful PCE
Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 is now a
WG draft.
Mutter!
Which document is right?
What specific issue are you raising?
[DD] http://tools.ietf.org/html/draft-ietf-pce-questions-03#section-20 says
| Stateless | Stateful |
------------------------+-----------+-----------+
Passive | 1 | 2 |
Active delegated LSPs | 3 | 4 |
Active suggest new LSPs | 5 | 6 |
Active instantiate LSPs | 7 | 7 |
7. These modes are out of scope for PCE as currently described.
Where does draft-ietf-pce-pce-initiated-lsp fits in, in my reading this was 7,
and thus I suggested it should not be out of scope.
If you agree, ignore below text.
Otherwise we have some confusion over the terms.
IMO 'Suggest new LSP' was same as PCE sends an update message triggering setup
of a new LSP in MBB fashion.
'Instantiate LSP' was PCE send an LSP initiate message to instantiate an LSP.
(7)
Maybe you can clarify what is your understanding of these terms.
OK, the difference I am trying to arrive at is whether the Active PCE can
*require* the establishment of an LSP, or whether it is *suggesting* it.
The difference is (IMHO) between an NMS or CLI that dictates what the LSR does,
and an Active PCE that requests the LSR to act.
More precisely, absent access controls, an LSR obeys the NMS, but an LSR can
implement policy to filter or modify requests from a PCE.
I realise that this view might not be popular with implementers of Active PCEs,
but I think that they are failing to distinguish between the blob of code they
are writing and naming "Company Foo's most Excellent Active PCE", and the
architectural components. This, at least, is part of what I am trying to convey
in Section 19 of this document and in the ABNO document.
The bottom line, I think, is that a PCE is not a provisioning tool, it is a path
computation element. The fact that PCEP is used as a provisioning protocol does
not make the thing that does the provisioning into a PCE.
Of course, I don't want to go against consensus with this, but I do think it is
an important architectural principle. Thus, I have been looking for words that
suit both viewpoints...
For an Active PCE to "suggest new LSPs" or to "recommend new LSPs" as described
in Sections 19 and 20 allows, IMHO, an LSR to have a policy that says "always do
what is recommended" and so achieving PCE-initiated LSPs. Yet, these words also
allow a policy of "look both ways before crossing the road" which fits more
closely with my world-view.
>From my perspective "sending an update message to trigger setup of a new LSP in
MBB fashion" is no different from setting up any other LSP. First there was no
LSP, then there is one. So I think the distinction you are drawing doesn't work.
I hope that explains my motivation, and I believe the words in the draft fit
this explanation.
Cheers,
Adrian
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
