Support, have following suggestions...
Sec 1. Introduction
A PCE or a
PCC operating as a PCE (in hierarchical PCE environment) computes
paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on
various constraints and optimization criteria.
I find 'PCC operating as a PCE' confusing here, it doesn't add any value,
perhaps you could say "A PCE or a set of cooperating PCEs compute ...."
Sec 3. Overview of PCEP Operation in SR Networks
o An ordered set of both MPLS label(s) and IP address(es): In this
case, the PCC needs to convert the IP address(es) into the
corresponding SID(s) by consulting its TED.
Do you mean a combination of label and corresponding IP address? Or some nodes
and links are represented as Labels and some with IP address? The description
seems to suggest the latter in which case it might be stated more clearly.
Furthermore, an LSP initially established
via RSVP-TE signaling can be updated with SR-TE path. This
capability is useful when a network is migrated from RSVP-TE to SR-TE
technology. Similarly, an LSP initially created with SR-TE path can
updated to signal the LSP using RSVP-TE if necessary.
The procedure to do so should be stated, the Path Setup Type TLV with the new
PST seems like an obvious solution, maybe this could be placed in
draft-sivabalan-pce-lsp-setup-type as a generic mechanism.
The extensions specified in this document are applicable to the
stateless PCE model defined in [RFC5440], as well as for the active
stateful and passive stateful PCE models defined in
[I-D.ietf-pce-stateful-pce].
[I-D.ietf-pce-pce-initiated-lsp] can be added to this list as well.
The SR Capability TLV is meaningful only in the OPEN message sent
from a PCC to a PCE.
I think you mean the MSD value inside the SR capability TLV and not the full
TLV itself?
Sec 5.3. ERO Object
Note that an SR-ERO subobject does not need to
have both SID and NAI. However, at least one of them MUST be
present.
To handle this case you suggest...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | ST | Flags |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SR-ERO subobject may have only SID, only NAI or both, and you list the various
combination of length possible for each ST type.
The figure above doesn't reflect that, as SID looks permanent.
Moreover, can the encoding be simplified by making SID encoding a must (as
shown in the figure in the draft) with a suitable NULL value reserved for the
case when SID is not present or simply the value is ignored when S flag is set.
Nits
- Expand LDP, RSVP-TE on first use
- Update reference filsfils-rtgwg-segment-routing to
draft-filsfils-spring-segment-routing
- SID Type (ST) can be listed independently and not clubbed with NAI
description in section 5.3.1
Hope the authors and WG find these useful.
Regards,
Dhruv
> -----Original Message-----
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of JP Vasseur (jvasseur)
> Sent: 14 September 2014 18:06
> To: pce@ietf.org
> Subject: [Pce] Adopting of draft-sivabalan-pce-segment-routing-03.txt as PCE
> WG Document
>
> Dear WG,
>
> We had several discussions showing a good consensus adopting draft-sivabalan-
> pce-segment-routing-03.txt and this work has considerably progressed in other
> WG.
>
> Are you in favor of adopting draft-sivabalan-pce-segment-routing-03.txt as a
> PCE WG document ?
>
> Thanks.
>
> JP and Julien.
>
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
