Hi Elwyn, Thanks a lot for your response. Please see my replies inline:
Best regards, Jie > >> s3.2, para 2: > >> OLD: > >> The ingress MUST ensure that the desired loopback mode is > >> strictly identified in the ERO. > >> > >> Am I right that "mode" is a typo? Should it be "node" rather than > >> "mode? I couldn't see anything about "loopback modes" in RFC 5860 or > >> RFC 6371. After much head scratching I came to the conclusion that "node" > >> was the right answer... If not then please explain where modes are > >> defined. > > I guess we may not call it a typo. The above sentence was added during the > WG review, the intention was to strictly identify the entity at which the > loopback is desired, which can be either a node or an interface of a node. > > > > If we replace "mode" with "entity", do you think it can be clearer? > > > >> Continuing on the basis that the word s/b "node"... I think this would > >> be clearer as follows: > >> NEW > >> The ingress node MUST ensure that the node where loopback is intended > >> to occur is marked as a strict hop (i.e., not a loose hop) in the ERO. > > If you agree with the above change, in your suggestion we can also > > substitute > "node" with "entity". > That would help. How about: > NEW (mk 2): > > The ingress node MUST ensure that the entity (node or interface), at which > loopback is intended to occur, is marked as a strict hop (i.e., not a loose > hop) in > the ERO type subobject. Agree with this description. Will update in the new revision. > > The prior subobject of "ERO Hop Attributes subobject" would also be ERO > subobject which identifies the target entity of loopback. As specified in the > sentence below, the type value of the prior subobject ensures the prior > subobject would be an IP prefix or an interface ID, which can identify the > node > or interface at which loopback is desired. Note that the current description > requires both the "ERO Hop Attributes subobject" and the prior subobject have > the L bit set to 0 to ensure that the two subobjects together strictly > specify a > loopback request on an specific entity (node or interface). > > > > We can rephrase to make it clearer. > I have looked into this issue a bit more deeply, and realize that my problem > is > not really with this draft but, at least partly, with > draft-ietf-teas-lsp-attribute-ro-01. Having gone back to RFC3209, I > understand that the subobjects in an ERO as defined there are all specifiers > for > type of 'entity' that could be waypoints on the explicit route. There is no > allowance for other types of subobject (such as the attribute subobjects being > introduced by draft-ietf-teas-lsp-attribute-ro-01). As introduced in RFC > 3209, > both EROs and RROs contained only entity type subobjects, but RFC 5420 > changed this for *RROs only* by introducing RRO Attributes subobjects which > could be inserted between the type subobjects. Thus as standardized currently, > EROs aren't allowed any other sort of subobject and there is no equivalent to > the "Presence Rules" defined for RROs in RFC 5420 section 7.3.1. > > draft-ietf-teas-lsp-attribute-ro-01 updates the presence rules for RROs to > allow > for the RRO Hop Attributes subobjects but the necessary presence rules that > would control where the ERO HOP Attributes could be inserted are not properly > defined in draft-ietf-teas-lsp-attribute-ro-01. Para 1 of s2.3 of > draft-ietf-teas-lsp-attribute-ro-01 seems to indicate that the HOP Attributes > would be placed after all the type subobjects which doesn't seem right. I > would have thought that the hop attributes needed to be interleaved between > the type subobjects - and I think that is what the existing text in the lock > draft is > trying to say. > > So I think the draft-ietf-teas-lsp-attribute-ro-01 needs to be clarified > - a specific section on Presence Rules as in RFC 5420 would help. > > The text about checking that the L bit in the lock draft is confusing, > because the > L bit is *required* by draft-ietf-teas-lsp-attribute-ro-01 > to be 0 in *all* Hop Attributes subobjects whether they are associated with > loose or strict hops and need not be mentioned. The L bit is only set in the > type subobject if it is a loose hop so the check should be > that the type subobject has its L bit clear. It should also be made > clearer in the lock draft that there can be multiple Hop Attribute subobjects > after the type subobject. > > I hope this helps. You are correct, the L bit in the ERO hop attributes subobject must be 0, thus we would only specify that the L bit in the prior ERO subobject MUST be set to 0 in the new revision. As for the rules about multiple Hop Attribute subobjects in ERO, IMO maybe it is more suitable to be specified in draft-ietf-teas-lsp-attribute-ro, but we can also add such descriptions if you think they belongs to this draft. > >> s3.2, para 3: > >>> Currently, the type value MUST be verified to be > >>> less than 32, and for type values 1 and 2 the prefix length MUST be > >>> 32 and 128 respectively. > >> It would be better to use the names of the types (1 = IPv4, 2 = IPv6) > >> that would make it clearer why the lengths are as they are specified. > >> Is it possible to explain why the type has to be less than this > >> apparently arbitrary limit of 32? And hence what allocation > >> constraints ought to be applied in the future - this might need a > >> change in the IANA allocation rules that should be specified in this > >> document. > > The limit of 32 was to ensure the subobject type can identify a specific > > node > or interface. Maybe we can specify the required types (node, interface) > explicitly to make it clear. > That would help. > It has just occurred to me why you want to say that the prefix lengths are > 32/128 bits - so that the IP address refers to exactly one node. > However this is possibly confusing because RFC 3209 *requires* the values to > be 32/128 respectively and the subobjects do carry just a host address and > not a > domain prefix as might be implied by lower values. As specified in 4.3.3 of RFC 3209, for the ERO subobjects, the prefix lengths are not required to be just 32/128. While as specified in 4.4.1 of RFC 3209, for the RRO subobjects, the prefix lengths are required to be 32/128. > I noted having looked again at the registry [1], and it appears that nobody > has > yet defined an ERO type for 4 octet AS numbers which have now > (finally) been standardized. This might mean that 32 was not the right > boundary. Perhaps this means that you need to define an update to the > allocation rules for the registry so that values below (say) 32 are required > to > identify exactly one physical node and not an abstract node with potentially > many physical nodes. Thanks for your suggestion. Since this draft just want to restrict the type of ERO subobjects that can appear prior to the ERO hop attributes subobject, making such update to IANA was not our original intention, also requires discussion with ADs and TEAS chairs. What about we specify the allowed ERO subobject types explicitly, similar to 6.1.1 of RFC 4990? The specification could be something like: The prior subobject MUST be able to identify a specific node or interface, specifically it MUST be one of the following: type "IPv4 prefix" with prefix length 32, type "IPv6 prefix" with prefix length 128, or type "Unnumbered Interface ID". > > [1] > http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml#rsvp- > parameters-25 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
