Dear Adrian,
Please find the comments inline..
Dear WG Chairs,
Once the WG has made the decision on the adoption, we can re-poll the WG and get consensus on the issue of encoding domain-sequence. Authors do have a preference but we are completely open for what the WG consensus dictates and revise the document accordingly.
Regards,
Dhruv
>-----Original Message-----
> From: pce-bounces <at> ietf.org [mailto:pce-bounces <at> ietf.org] On Behalf Of Adrian
> Farrel
> Sent: Tuesday, April 03, 2012 3:54 PM
> To: 'Ramon Casellas'; pce <at> ietf.org
> Subject: Re: [Pce] Adopting draft-dhody-pce-pcep-domain-sequence-02 as a new
> PCE WG
>
> Hello Ramon,
>
> >> I understand the motive for this work and, indeed, it fills a hole in the
> protocol spec.
> >
> > [Ramon] if you could elaborate a bit more on which hole(s) exactly, I would
> > make sure that we can come up with a more satisfactory proposal, e.g a) the
> > lack of (some?) route sub-objects for domain encodings, b) the ordering
> > constraints, c) decoupling and relationship between PCE-sequences and
> > domain-sequences? (personally, I find a) and b) more important.)
>
> I find a) most important.
> As far as I am concerned, the PCE sequence is already decoupled from the IRO.
> I find the way that this I-D decouples the domain sequence from the path
> "inconvenient".
>
[Dhruv Dhody>] We feel the decoupling allow us to handle IRO better. As PCE is used in multiple situations, use of new type IRO for encoding domain sequence kept the meaning of IRO but allowed us to define better rules. We can poll again to get a rough consensus on this.
> >> I do hope that the authors are building it for shipping equipment and
> deployment. If
> >> not, would they please consider whether it should be experimental?
> >
> > [Ramon] I have no objection at being experimental, what option the WG
> things
> more
> > appropriate is fine for me.
>
> Open issue for the chairs to drive.
>
> >> I am concerned that this document changes the definition and intent
> contained
> in
> >> RFC 5440. In my opinion the authors of 5440, and the WG at the time, went
> to
> >> some lengths to tie the content of objects in PCEP to the same definitions
> found
> >> in RFCs 3209, 3473 and 3477. At the same time, definitions of subobjects
> for
> path
> >> definition, should also pay attention to RFCs 4874 and 4920. The intention
> is
> to not
> >> define more subobjects than needed and to keep registries aligned
> >
> > [Ramon] agreed, and this is the intention. See also my other comments below
>
> Excellent. So it is probably just nits.
>
> > [Ramon] I would really appreciate your thoughts on whether [E/X/R/I]RO
> > sub-objects for OSPF-TE areas and IS-IS areas are needed, as well as 4-byte
> > AS (unlike TLVs, 4 byte AS and 2-byte AS sub-objects cannot share the
> > encoding). This is in line with your concern whether more sub-objects are
> > needed or not, which should also be brought to ccamp attention as well.
> >
> > Some (initial, loose) discussions on the need for IGP sub-objects were
> > indirectly discussed in
> http://www.ietf.org/mail-archive/web/pce/current/msg02561.html
>
> We need to consider two "fringe" conditions.
>
> 1. A PCE serves multiple domains. In this case, if the PCC wishes to control
> the
> domain path, it needs to be able to specify domain IDs as inclusions and
> exclusions.
>
> 2. There may be segments of the path where per-domain signaling is needed. In
> this case there needs to be an exchange of objects (back and forth) between
> PCEP
> and RSVP-TE in order to achieve control of the domain path.
>
> That said, in my experience, the domain paths in current deployments are not
> long, and border routers are often known a priori.
>
[Dhruv Dhody>]
1. PCE serving multiple domains is easily handled in the domain-sequence where a PCE is well aware that it can handle one or more domains in the sequence. We can further check allowing Explicit Exclusion Route subobject (EXRS) in the domain-sequence.
2. In case of per-domain signaling with loose path, we see little use of domain-sequence, this could be explicitly mentioned in the document.
> >> It is also worth noting how 4920 handles 2 and 4 octet AS numbers and
> that
> >> there is overlap in the definition of AS number subobjects with
> >> draft-zhang-pce-hierarchy-extensions-01
> >
> > [Ramon] We had considered 4920 for this, although the proposed encodings
> > are as TLVs (for IF_ID ERROR_SPEC objects) and this i.-d. work was
> (arguably)
> > regarding route objects. I agree that, as TLV encodings, a single 4 byte
> encoding
> > for both 2-4 bytes AS makes a lot of sense, specially since the 16-bit
> sub-registry
> > is common. This would also solve the problems regarding IGP areas.
> >
> > If I may, what kind of encoding would you suggest? In previous discussions
> it
> > was suggested that we should use the IRO for the problem we were trying to
> > solve , which somehow precludes the use of TLVs unless wrapped in a ERO
> > subobject (had we been given the green light for a new object, which is not
> > necessarily the right thing to do, I would be happy to use 4920 tlv
> encodings
> > for this)
>
> I guess I would need to look at this in more detail. I don't see a lot of
> difference between a TLV encoding and a subobject encoding. The main
> difference
> is the codespace the T values come from. Obviously, you can't munge the two
> code
> spaces, but you can share encodings.
[Dhruv Dhody>] We all agree that new subobjects are needed, as far the encoding of those subobjects its important for us to keep it aligned to the definition of other subobjects, as per general subobjects definition:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
We did follow this guidelines, where as the TLV require following encoding which would be incompatible with subobjects encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> > [Ramon] AS number subobjects and all common IANA registry requests between
> > this draft and draft-zhang-pce-hierarchy-extensions-01 MUST be unified and
> being
> > involved in both we make sure they will.
>
> Perfect.
>
> >> In this light and on careful reading, the IANA section is somewhat broken
> and
> >> confused about what should be in the registry it is creating.
> >
> > [Ramon] agreed, and most importantly, it must also be brought to ccamp
> > attention as well.
>
> Good idea
>
> >> But I am also unsure why a new IRO type is needed. Surely the domain
> >> sequence that is used in the computation is also the domain sequence
> >> for the path that the LSP will take. This feeds on the points below.
> >
> > [Ramon] The main rationale behind this discriminator is the ordering
> > constraint, since (my guess) no ordering assumption could be inferred
> > from rfc5440. IIRC this was confirmed (I am sorry I wasn't in Taipei, I
> > may be wrong).
> > Quoted from a past mail:
> > http://www.ietf.org/mail-archive/web/pce/current/msg02580.html
> >
> > "Unfortunately RFC5440 does not mention anything regarding sub-object
> > ordering, it only says "to specify that the computed path MUST traverse
> > a set of specified network elements" and does not include some text in
> > the spirit of "Objects within an IRO object MUST appear in the resulting
> > ERO in the same order that they appear in the IRO". Unless I am mistaken,
> > this means that, at least in theory, we should not make assumptions
> > whether the sub-objects included in the IRO shall appear in the resulting
> > ERO in the same relative ordering". As an RFC 5440 co-author maybe you
> > can comment on this? is the ordering implicit?
>
> Very good quote. Yes, this uncovers the ordering issue with the IRO. And,
> thinking back, it was exactly the intention that the IRO did not imply any
> ordering. Usually, I think, the IRO would contain a small number of
> nodes/links
> to give hints to the computation, or to take the path through key points in
> the
> network.
>
> So, this is a bigger issue than just the domain sequence: how does the PCC
> request an ordering of path elements?
>
> The answer may be that it should not need to. Maybe, even, that it has no
> meaning for it to do so.
> This answer could apply equally to nodes, links, or domains.
>
> I think this can be proved by drawing a picture. If there is the possibility
> to
> route a path from domain X through domains A, B, C, and D to domain Z, why
> should the PCC state the order that they must be traversed? Surely the PCE
> will
> work out which is the better path XABCDZ or XACBDZ. If, on the other hand,
> the
> only possible path is XABCDZ then the PCC does not need to worry about the
> order
> of the domains it lists in the IRO because the PCE can only produce one
> result.
>
> Now, I can hear in my head the people saying that it is more complicated if
> the
> PCE has to work out the ordering of the domains, but I wonder why this is
> more
> complicated than working out the ordering of nodes. And I do think that the
> PCC
> should be spared the complexity of knowing or working out any sequencing for
> the
> path.
[Dhruv Dhody>] Domain sequence would either be pre configured or computed by some other means (eg. HPCE). Incase of HPCE, Parent PCE can determine the correct order and specify the order as its usually done in ERO; incase of admin has configured it at PCC, IMHO admin is well aware of the sequence (it is a sequence afterall).
I am aware of some implementation of CSPF that requires ordering esp in case of strict hops. So I do believe in my opinion the complexity of PCE to figure out domains on its own is high.
Also consider P2MP where if the order is not considered the complexity of the algorithm at PCE will only increase.
> > In any case, the actual solution and encoding is open to discussion. IF
> > the ordering inclusion is implicit, I have no objection for using the
> > existing IRO and this includes your subsequent concerns with its contents.
> >
> >> The algorithm in 3.4:
> >> - assumes only area IDs and AS numbers
> >> - assumes that a PCE knows at least one PCE responsible for
> >> each of its neighboring domains
> >
> > [Ramon] afaik, the algorithm was added recently in order to simplify the
> > (apparently overkill and over-)specification of the IRO sub-objects which
> > was also proposed by me in the aforementioned mail
> > web/pce/current/msg02580.html (which tried, as a informational exercise,
> > to also capture intra-domain objects). The motivation behind both is to
> > clarify its usage. Depending on the outcomes of this and further
> discussions
> > they can be elaborated, removed (by relying on the existing documents) or
> > clarified.
>
> OK
>
> >> I would like the authors to take care that the identity of a boundary node
> >> does not uniquely identify a next-hop domain (even if it may be
> >> successfully used for domain routing given the knowledge of the next
> >> domain, next boundary node, or egress node) and the text should not
> >> imply that it does. This is hidden at the end of 3.4 some time after the
> >> boundary node/link discussion.
> >
> > [Ramon] point taken. we will review the text accordingly.
> >
> >> Shouldn't you allow "loose" hops in the domain path? (i.e. gaps between
> >> domains).
> >
> > I don't see any special reason why we shouldn't, although one concern I
> > have is how would this relate to RFC5440 statement "The L bit of such
> > sub-object has no meaning within an IRO"?
>
> Ah, my bad. As above, the original (type 1) IRO has no ordering or tightness
> of
> sequencing. Thus, it is just a list of things to include.
>
> *if* you stay with the type 2 IRO, and *if* you define ordering in the type 2
> IRO (as currently written), then you need to consider the L bit.
>
[Dhruv Dhody>] Yes we will!
> >> Can I also mix other concepts with the domain path? What about a
> consistent
> >> lambda, or a core node that needs to be on the path?
> >
> > [Ramon] IMHO, there are two (decoupled) points here:
> >
> > a) whether the current IRO has ordering constraints or not
> >
> > b) If a new IRO is needed whether only domain-related info is conveyed.
> >
> > An (authoritative 
) answer for a) would be much appreciated.
>
> Ask JP
>
> My reading agrees with yours (and my memory) as above. The IRO is just a set
> of
> objects to be included. Presenting the elements of the set in any order will
> have the same result (plus or minus ECMP situations and peculiarities of
> specific PCE implementations).
>
> > There was also the concern of separating the roles of intra-domain path
> > computation IRO and the resolution of PCEs in a collaborative setting.
>
> I'm not entirely sure I get this point. A PCE can only compute a path segment
> that goes through its domain of responsibility - it will find all elements in
> the IRO that it recognises as "local" and include them in the segment it
> makes,
> and it will pass on all other elements to the other PCEs it cooperates with.
> There is clearly a task for the "aggregating PCE" (which may be the head of
> the
> chain, or may be the parent) to put the segments together according to the
> complete IRO.
[Dhruv Dhody>] In case of BRPC where the computation starts from the PCE(n); domain-sequence serves the important purpose of reaching domain(n); if a PCE has to go through IRO which has intra-domain segments (node, links) plus the information on domain-sequence, it gets bit complicated to handle. We specify clear separation for the very same reason. We can provide suggested handling when both IRO of type 1 and 2 exist.
>
> > For b), if we agree on the idea "the new object type imposes
> > ordering constraints" I would not be against being like any other
> > IRO. With a new IRO type we can be more concrete regarding the
> > role of the must-process p-bit, what to do with unknown objects
> > (locally to a PCE) i.e., nothing is said in IRO and XRO objects what
> > the procedures are when a sub-object is "not found" (in the TED?).
>
> This seems to cut to a complexity question.
> We could allow a PCC to specify as much or as little of the information about
> the path as it likes. This is certainly fully flexible, but it seems to me to
> masively over-complicate the protocol and the functional model. Isn't it the
> case that the PCE is capable of selecting the *best* path. Thus, for example,
> there is no need for the PCC to say "I want a continuous lambda for the
> segment
> over domain X" because that implies the PCC knows stuff about domain X that
> the
> PCE is unaware of.
[Dhruv Dhody>] Domain-sequence is made of domains(AS and area) and *optional* Boundary information (ABR, ASBR, inter-as links). All this information is known to the admin as thus configured at PCC or learned via parent PCE. I don’t think there is any information here that only PCC is aware of where as PCE is not.
Also PCC can continue to specify as little information and continue to use the existing mechanims.
>
> > From the mail: "it is not clear to me what should be the default
> > procedure for an unkonwn IRO subobject. It could be ignored or
> > it could trigger an error. If we apply this to the domain sequence,
> > I would say that an unknown subobject at this level should trigger
> > some kind of high level error, like "PCE domain chain broken" or
> > similar"
>
> That is a good question, and there are two sub-species of "unknown". The
> processing collapses to the same behavior, but it is worth looking at them
> separately.
>
> 1. I know the T value, but I can't find the identified resource
> 2. I don't know the T value.
>
> In the first case, the PCE processes the IRO to include as many of the
> elements
> of the IRO as possible. If the PCE is passing the request onwards, it is OK
> for
> it to fail to find the resource, and it can assume that the next PCE might be
> able to satisfy the remaining elements of the IRO. On the other hand, if the
> PCE
> is making an end-to-end (or edge-to-edge, or end-to-edge) path and will
> return
> the response to a PCC (rather than pass it on) then the PCE must fail if it
> cannot satisfy the IRO (this failure behavior is in RFC 5440).
>
> Now, I would hold that the second case can be handled identically to the
> first
> case.
>
> And ultimately, when the path segments are aggregated by a head-end PCE or by
> a
> parent PCE, that PCE can check to see whether any elements of the IRO are
> still
> missing.
>
> There is, just one wrinkle in that case which is that the aggregating PCE
> must
> understand all of the T values, or the IRO must be stripped and returned on
> the
> response messages.
>
[Dhruv Dhody>] At a time when we are considering enhance error and notification handling [draft-pouyllau-pce-enhanced-errors], its important that our inter-domain mechanism specify errors correctly and propagate them to the PCC. In this document we made a humble attempt to specify the scope of the IRO and clear error handling.
> >> In 3.5.7 I don't see that the domain sequence is necessarily an
> alternative
> >> to the PCE sequence. There are cases where even with a domain sequence,
> >> a PCE sequence is important.
> >
> > [Ramon] Personally, (although we still need to discuss it more) I don't see
> > domain-sequence and pce-sequence as exclusive and I agree they can
> > coexist. The whole 3.5.7 needs to be revisted, including J.P. comments
> > during the meeting that some assertions were false (which is true, brpc
> > may benefit from a domain sequence but does not require it)
>
> Agrred
>
> >> Section 5 will need loads of work because the domain sequence (even
> >> for inclusion, not reporting) provides information valuable to an
> attacker.
> >
> >[Ramon] agreed.
> >
> > Thanks again,
> > Ramon
>
> Very welcome.
> Most fun I have had all year 
>
> Adrian
>
> _______________________________________________
> Pce mailing list
> Pce <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pce
RSS Feed