|
Hi Jean-P and Jean-L,
Thanks for this draft and for splitting the work
out into this and the two IGP-specific drafts as requested by the
ADs.
As you'll have seen, there is no slot for this on
the San Diego agenda. Sorry, not enough time. But we will mention the draft from
the chair, and I plan to take a sense of the room as to whether this is now
ready to be adopted by the WG as a necessary building block for more advanced
TE.
Folks reading this email might want to look at
the draft to prime their pumps (and there is nothing that should prevent anyone
commenting about the draft on the mailing list).
I have a few minor comments, but the general
thrust is that this draft may still include too much information specific to
different situations. For example, if we decided to sit on PCE for while because
we are not sure how to proceed, would that mean that we really wanted to block
the development of TE node capabilities? The normal approach for this sort of
work would be to define the generic objects/TLVs and processing rules, but leave
the definition of sub-object/TLVs to individual drafts for each new
function.
Cheers,
Adrian
Document alignment
Could you get the next version to start in column
0 and end in column 72 so that I can print it, please.
Section 2. Terminology
< PCE: Path Computation Element
whose function is to compute the
< path of a TE LSP it is not the head-end for. The PCE may be < an LSR or an offline tool not forwarding packet. > PCE: Path Computation Element
whose function is to compute
the
> path of a TE LSP for which it is not the head-end. The PCE >
may be an offline tool and may be located on an LSR or
some
>
other node not forwarding packets for the LSP.
< PCC: Path Computation Client (any head-end LSR) requesting a TE < LSP path computation to the Path Computation Element. > PCC: Path Computation Client (any LSR) requesting a path > computation from the
Path Computation Element in support of
> a
TE LSP.
< Intra-area TE LSP: TE LSP whose
path does not transit across
< areas. > Intra-area TE LSP: TE LSP whose path does not transit across > IGP areas. Section 3. Introduction
< The current MPLS-TE/GMPLS
routing focuses on TE link information. In
< return TE router information are limited to the TE router id. > The current MPLS-TE/GMPLS routing focuses on TE link information. TE > router information is limited to the TE router id. < - A Path Computation Elements
(PCE) can compute paths for TE-LSPs
< it is not the head-end for. > - A Path Computation Elements
(PCE) can compute paths for TE-LSPs
> for which it is not the head-end. It would be highly useful that a node
advertise its PCE capabilities so as for the LSRs in the network to automatically discover PCEs in addition to their capabilities, and thus would reduce the LSR configuration overhead. This would also allow for the dynamic discovery of a new PCE or that a PCE is not longer alive. ## We need to be clear that this is not a case of using the IGP
## to distribute topology or forwarding/data plane capabilities.
## This is an example of "overloading" the IGP with application
## capabilities of the router. In fact, there is an assumption
## here that PCE function is offered by routers that are
## actively participating in the IGP - I see no reason to make
## this assumption, but perhaps this is up for discussion in the
## PCE BOF (to which everyone is invited).
## ## My concern is that we are opening up the IGPs to be general
## information distribution protocols. This is clearly the thin
## end of a very large wedge, and we need to be extremely careful
## how we manage the growth of information that is added to IGP
## advertisements.
- Data plane capabilities related to the node itself
## I think you should split this bullet into two. One to cover
## data plane capabilities, and one to cover control plane
## capabilities. (you have done this in section 4)
##
## You could add to the data plane capabilities GMPLS cross-type
## switching capabilities.
- A TE mesh group is a group of LSRs that are connected by a full
## Again, my concern is that you are suggesting to overload the IGP
## with information that is not routing information, but group
## membership application and discovery. We have to be very careful
## how we manage such extensions to link state routing protocols.
##
## I have a question about general deployment: do you see groups as
## being built typically of edge nodes (i.e. PEs) or will they have
## arbitrary membership?
Section 4.2. Required
Information
M bit: when set, this flag indicates that the LSR supports MPLS-TE signalling ([RSVP-TE]). G bit: when set this flag indicates that the LSR supports GMPLS signalling ([RSVP-G]). ## Two issues.
##
## Firstly, while this information may be useful on a per-router
## basis, isn't it also important to know on a per-interface
## basis? That is, where there is in-band signaling, the MPLS TE
## protocol can usually be turned on or off per interface. In all
## cases, the availability of (G)MPLS TE forwarding may also be
## configured per interface. Doesn't this information need to be
## added to the link capabilities?
##
## Second. How are you defining a precise distinction between MPLS
## TE and GMPLS TE? Is it simply by the use of the Generalized
## Label, or is there some more complex issue with regard to
## the protocol extensions that are supported?
Section 4.3 Procedure
TE Node Capability Descriptor TLVs are optional. When a Link
State
Advertisement does not contain any TE Node capability Descriptor TLV, this means that the TE Capabilities of that LSR are unknown. ## How is this future-proofed. If a new bit flag is defined in the
## future for some new attribute ("can the router walk and chew gum
## at the same time") existing routers will include the TLV, but will
## not report on the ambulatory masticatory capabilities of the
router.
## How will these new bits be interpreted?
## I think this can be handled through a careful statement of meaning
## since it seems likely that old routers will not support new
## function.
Section 5.1 Description
## Suggest that you say that the selection between available PCEs is
## out of scope.
Section 5.2 Required Information
## I'm afraid that this section is premature. I know that more bits
## and associated information can be defined, but precisely what is
## needed in support of PCE is very unclear at this stage and is
## probably a matter for the PCE BOF.
##
## One example, is that the smallest unit that a PCE can advertise
## here is full area capabilities. It seems to me that a
computational
## domain may often be smaller than an IGP area.
D bit:
## How do you handle the intersection of computational scope and
## diversity capabilities? It is possible that a PCE will be able
## to provide inter-area paths, but not guarantee their diversity.
## But it will be able to guarantee diversity for intra-area paths.
Section 6.2 Required information - A Tail-end name: string used to ease the TE-LSP naming
(e.g.
head-name->tail-name'). ## I'm not sure exactly what you mean.
## Does this name specify the name of the LSR that is adding
## itself to the mesh group? That is, the name of the LSR to
## which each other LSR in the group MUST establish a TE LSP?
## Why is this a different name for each group to which the
## LSR belongs? Surely that will/could lead to the distribution
## of a lot of duplicate text strings. Isn't it enough to have
## a single LSR/router name as a node property?
## How do group members know how much bandwidth to request for
## the TE LSPs between themselves and other group members?
7. Security Considerations
## Although you don't raise new security issues because you
## don't define any new protocol elements, I do think you
## need to give some more guidance to the IGP WGs.
## What would be the consequence if any of this information
## was intercepted? modified? spoofed?
Informative References
[RSVP-P2MP]
## Draft name changed under your feet.
|