Brilliant! Thanks, Dhruv. I think we are down to two points.
>> 3.1.1. is a lot better, thanks. >> >> You have... >> The inclusion of this TLV in an OPEN object indicates that the H-PCE >> extensions are supported by the PCEP speaker. The child PCE MUST >> include this TLV and set the P flag. The parent PCE MUST include >> this TLV and unset the P flag. The PCC MUST include this TLV to >> indicate that it understands the H-PCE extensions with P flag unset. >> >> The first two sentences are good: the function allows two PCEs to work out >> the direction of the relationship between them. >> >> However, I don't understand the final sentence. Why would a PCC need to >> indicate that it understands the H-PCE extensions? Given that it: >> - cannot be a parent PCE because it is not a PCE >> - cannot be a child PCE because it is not a PCE ...why would it ever >> indicate that it supports the H-PCE extensions? Actually, why would it >> ever be implemented to support those extensions? Furthermore, by including >> the TLV but not setting the P flag, it gives the impression that it is >> willing to be a parent PCE. > > [[[Dhruv Dhody]]] We want the PCC and child PCE to include this TLV in case > they would like to use this PCEP extension, which includes various new > information that can be encoded in PCReq from PCC towards the child PCE > such as - RP object changes (section 3.2) and new OF codes and inclusion of > TLV (section 3.3) etc. > > We would like this to be done on a PCEP session between PCC towards child > PCE when we know that this child PCE understands the H-PCE extension as > described in this document. > > The setting of P flag (parent PCE request bit) means that the PCEP speaker > wants the peer to be a parent PCE, so in the case of PCC_Child-PCE both > parties do not set the bit. Firstly, I wonder whether we are confusing ourselves (or I am confusing myself :-) with the terms PCC and child-PCE. Of course, in some senses the child-PCE acts as a PCC in its relationship with the parent-PCE, but it might help if we consider the strict three entities and relationships as: parentPCE----childPCE----PCC Now, with the representation, we must ask why would a PCC ever use these extensions? You are suggesting that the PCC might want to use features such as the new OFs, and that is reasonable if we define these as "multi-domain OFs" and not actually anything to do with H-PCE. For example, if the PCC's PCE uses BRPC or any other magic, those OFs would still apply. > Dan, maybe we should we spell this out more clearly? OK. Now I understand what you want to do, it is relatively simple. What we need is a description (like we have arrived at above) of when and why a PCC might use these extensions, and a statement (like you just gave) that in those circumstances the PCC and the child PCE are not acting in parent-child relationship, but that the extensions are being used so that the child PCE may pass them on to the parent PCE. That doesn't feel like more than one or two short paragraphs. Probably worth putting them in a new subsection "Applicability to PCC-PCE Communications" relatively high up the document. >> In 3.3.1 you fixed up MBN nicely so that I can understand it. Thanks. >> >> Except that you have made the description work well for IGP areas/levels >> and not so well for ASes. In other words, you cope well with the situation >> where the domain boundary is on the node, but not well when it is on the >> link. >> That is, to which domain does the inter-AS link belong? I should think >> that both ASes might consider it belongs to them and your algorithm might >> not count it at all. Alternatively, both might think it doesn't blong to >> them and you might count it twice. >> >> Aren't you actually trying to minimise domain transitions (which is >> different from MTD)? Wouldn't it be easier to say so? This especially >> since the Metric in 3.4 counts domains. >> >> I could re-draft the description of MBN in line with this if that would >> help, but I don't want to do that if I have misunderstood your objective >> to "minimise the number of domain transitions". > > [[[Dhruv Dhody]]] I was assuming that when inter-domain link is encountered, > it is NOT considered as part of the domain. > > .....AS100-----X---ASBR1---ASBR2---Y----AS200..... > > D(Lpi = X-ASBR1) = 1 (because X-ASBR1 and ASBR1-ASBR2 belong to different > domains) > D(Lpi = ASBR1-ASBR2) = 1 (because ASBR1-ASBR2 and ASBR2-Y belong to different > domains) > > So in case inter-AS it is counted twice, it is domain transition from my PoV. > > Could you think of a way to make this clearer? Right, so your algorithm counts 1 for each ABR when there is a domain transition, and 1 for each ASBR when there is a domain transition. I see that this is counting “border nodes only when there is a domain transition” and is counting each border node. That works. It is slightly counter intuitive (to me) because I would have wanted to count domains (which this doesn’t do). But OK. There is a potential issue in that you favour ABRs over ASBRs in this case. That probably doesn’t matter except for convoluted IGP area construction with virtual or pass-through links. So, no change to this section needed. It is doing what you intended and my mistake was to try to make it do what I intended! Thank you so much for this constructive engagement. I realise it comes very late in the process and so I am doubly grateful for your accommodation of my concerns. Best, Adrian -- Fairy tales from North Wales brought to you for Christmas https://www.feedaread.com/profiles/8604/ Available from your favourite online bookseller. Or contact me to receive a signed copy by mail. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
