Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi Elwyn, Lou, Thanks a lot for the comments. I agree with the new texts and will use them in a new revision. Regarding the label subobject, as Lou pointed out in a previous mail, it may be used in some technologies to identify a loopback target, thus it would be better to keep this document general about such cases. Best regards, Jie -Original Message- From: Lou Berger [mailto:lber...@labn.net] Sent: Sunday, March 01, 2015 2:28 AM To: Elwyn Davies; Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Elwyn, Thanks for the comments. I think your new text is fine. (And not materially different than the current text.) Lou On February 28, 2015 1:00:09 PM Elwyn Davies elw...@dial.pipex.com wrote: Hi, Jie. I think two conversations got a bit crossed here. I just checked the final version of -04 as submitted and saw that you had completely reverted the text about the types (as opposed to the version with the earlier email to which the comments below applied). The submitted version is pretty much OK because of the rule change, but I think that my original comments about identifying what type 1 and type 2 actually are is desirable, and it would be useful to say why 32 is the limit: OLD (i.e. submitted -04): 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. NEW: Currently, the type value MUST be verified to be less than 32 (i.e., able to identify a specific entity where a loopback can occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 (IPv6 address), the prefix length MUST be 32 and 128 respectively. Sorry about the confusion. I am not an expert in this area, but looking at your conversation with Lou about label subobjects I saw from RFC 3473 that, if present, one or two label subobjects MUST follow an IP address subobject that identifies the node/interface. It doesn't seem to indicate that a label subobject can occur on its own as an entity identifier to which attributes can be attached. Lou seemed to think there were cases where it could, but I don't see that being allowed. This may need clarification. This also may screw up the words about where to put ERO HOP attributes in the attributes draft. I'll follow that up separately. /Elwyn On 26/02/2015 13:07, Elwyn Davies wrote: Hi, Jie. I checked through the updated draft (-04) that you sent out. That all looks fine except for a couple of typos: s3.2, para 2: s/Explicit Route object/Explicit Route Object/ s5, para 2: s/to remains/to remain/, s/also applies/also apply/ With the added IANA consideration that you have been discussing with Lou we should be all done. I'll continue progressing the presence rule comments with the attribute-ro authors. Thanks for the work. Regards, Elwyn On 26/02/2015 06:15, Dongjie (Jimmy) wrote: Hi Lou, Thanks a lot for your prompt response. I see that label may be used for some technologies, so I will update the draft following your guidance: keep the previous text and update the IANA allocation rules for type value 5-31. Thanks. Best regards, Jie -Original Message- From: Lou Berger [mailto:lber...@labn.net] Sent: Thursday, February 26, 2015 11:40 AM To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Jie, see below. On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Why not? This is a technology specific issue. For example, one could loop a specific lambda in certain optical switches by identifying a specific lambda via a label. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. I think the previous text should be used. Thanks, Lou Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi, Jie. I think two conversations got a bit crossed here. I just checked the final version of -04 as submitted and saw that you had completely reverted the text about the types (as opposed to the version with the earlier email to which the comments below applied). The submitted version is pretty much OK because of the rule change, but I think that my original comments about identifying what type 1 and type 2 actually are is desirable, and it would be useful to say why 32 is the limit: OLD (i.e. submitted -04): 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. NEW: Currently, the type value MUST be verified to be less than 32 (i.e., able to identify a specific entity where a loopback can occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 (IPv6 address), the prefix length MUST be 32 and 128 respectively. Sorry about the confusion. I am not an expert in this area, but looking at your conversation with Lou about label subobjects I saw from RFC 3473 that, if present, one or two label subobjects MUST follow an IP address subobject that identifies the node/interface. It doesn't seem to indicate that a label subobject can occur on its own as an entity identifier to which attributes can be attached. Lou seemed to think there were cases where it could, but I don't see that being allowed. This may need clarification. This also may screw up the words about where to put ERO HOP attributes in the attributes draft. I'll follow that up separately. /Elwyn On 26/02/2015 13:07, Elwyn Davies wrote: Hi, Jie. I checked through the updated draft (-04) that you sent out. That all looks fine except for a couple of typos: s3.2, para 2: s/Explicit Route object/Explicit Route Object/ s5, para 2: s/to remains/to remain/, s/also applies/also apply/ With the added IANA consideration that you have been discussing with Lou we should be all done. I'll continue progressing the presence rule comments with the attribute-ro authors. Thanks for the work. Regards, Elwyn On 26/02/2015 06:15, Dongjie (Jimmy) wrote: Hi Lou, Thanks a lot for your prompt response. I see that label may be used for some technologies, so I will update the draft following your guidance: keep the previous text and update the IANA allocation rules for type value 5-31. Thanks. Best regards, Jie -Original Message- From: Lou Berger [mailto:lber...@labn.net] Sent: Thursday, February 26, 2015 11:40 AM To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Jie, see below. On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Why not? This is a technology specific issue. For example, one could loop a specific lambda in certain optical switches by identifying a specific lambda via a label. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. I think the previous text should be used. Thanks, Lou Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Elwyn, Thanks for the comments. I think your new text is fine. (And not materially different than the current text.) Lou On February 28, 2015 1:00:09 PM Elwyn Davies elw...@dial.pipex.com wrote: Hi, Jie. I think two conversations got a bit crossed here. I just checked the final version of -04 as submitted and saw that you had completely reverted the text about the types (as opposed to the version with the earlier email to which the comments below applied). The submitted version is pretty much OK because of the rule change, but I think that my original comments about identifying what type 1 and type 2 actually are is desirable, and it would be useful to say why 32 is the limit: OLD (i.e. submitted -04): 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. NEW: Currently, the type value MUST be verified to be less than 32 (i.e., able to identify a specific entity where a loopback can occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 (IPv6 address), the prefix length MUST be 32 and 128 respectively. Sorry about the confusion. I am not an expert in this area, but looking at your conversation with Lou about label subobjects I saw from RFC 3473 that, if present, one or two label subobjects MUST follow an IP address subobject that identifies the node/interface. It doesn't seem to indicate that a label subobject can occur on its own as an entity identifier to which attributes can be attached. Lou seemed to think there were cases where it could, but I don't see that being allowed. This may need clarification. This also may screw up the words about where to put ERO HOP attributes in the attributes draft. I'll follow that up separately. /Elwyn On 26/02/2015 13:07, Elwyn Davies wrote: Hi, Jie. I checked through the updated draft (-04) that you sent out. That all looks fine except for a couple of typos: s3.2, para 2: s/Explicit Route object/Explicit Route Object/ s5, para 2: s/to remains/to remain/, s/also applies/also apply/ With the added IANA consideration that you have been discussing with Lou we should be all done. I'll continue progressing the presence rule comments with the attribute-ro authors. Thanks for the work. Regards, Elwyn On 26/02/2015 06:15, Dongjie (Jimmy) wrote: Hi Lou, Thanks a lot for your prompt response. I see that label may be used for some technologies, so I will update the draft following your guidance: keep the previous text and update the IANA allocation rules for type value 5-31. Thanks. Best regards, Jie -Original Message- From: Lou Berger [mailto:lber...@labn.net] Sent: Thursday, February 26, 2015 11:40 AM To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Jie, see below. On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Why not? This is a technology specific issue. For example, one could loop a specific lambda in certain optical switches by identifying a specific lambda via a label. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. I think the previous text should be used. Thanks, Lou Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi, Jie. I checked through the updated draft (-04) that you sent out. That all looks fine except for a couple of typos: s3.2, para 2: s/Explicit Route object/Explicit Route Object/ s5, para 2: s/to remains/to remain/, s/also applies/also apply/ With the added IANA consideration that you have been discussing with Lou we should be all done. I'll continue progressing the presence rule comments with the attribute-ro authors. Thanks for the work. Regards, Elwyn On 26/02/2015 06:15, Dongjie (Jimmy) wrote: Hi Lou, Thanks a lot for your prompt response. I see that label may be used for some technologies, so I will update the draft following your guidance: keep the previous text and update the IANA allocation rules for type value 5-31. Thanks. Best regards, Jie -Original Message- From: Lou Berger [mailto:lber...@labn.net] Sent: Thursday, February 26, 2015 11:40 AM To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Jie, see below. On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Why not? This is a technology specific issue. For example, one could loop a specific lambda in certain optical switches by identifying a specific lambda via a label. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. I think the previous text should be used. Thanks, Lou Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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. Fine. 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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi Elwyn, Thanks a lot for your comments, these typos are fixed and the new revision has been submitted. Best regards, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 9:07 PM To: Dongjie (Jimmy); Lou Berger; General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I checked through the updated draft (-04) that you sent out. That all looks fine except for a couple of typos: s3.2, para 2: s/Explicit Route object/Explicit Route Object/ s5, para 2: s/to remains/to remain/, s/also applies/also apply/ With the added IANA consideration that you have been discussing with Lou we should be all done. I'll continue progressing the presence rule comments with the attribute-ro authors. Thanks for the work. Regards, Elwyn On 26/02/2015 06:15, Dongjie (Jimmy) wrote: Hi Lou, Thanks a lot for your prompt response. I see that label may be used for some technologies, so I will update the draft following your guidance: keep the previous text and update the IANA allocation rules for type value 5-31. Thanks. Best regards, Jie -Original Message- From: Lou Berger [mailto:lber...@labn.net] Sent: Thursday, February 26, 2015 11:40 AM To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Jie, see below. On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Why not? This is a technology specific issue. For example, one could loop a specific lambda in certain optical switches by identifying a specific lambda via a label. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. I think the previous text should be used. Thanks, Lou Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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. Fine. 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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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. Fine. 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. OK. 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. I will negotiate with the authors of draft-ietf-teas-lsp-attribute-ro to see if we can agree a revision. s3.2, para 3: Currently, the type value MUST be
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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. Fine. 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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Jie, see below. On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Why not? This is a technology specific issue. For example, one could loop a specific lambda in certain optical switches by identifying a specific lambda via a label. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. I think the previous text should be used. Thanks, Lou Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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. Fine. 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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi Lou, Thanks a lot for your prompt response. I see that label may be used for some technologies, so I will update the draft following your guidance: keep the previous text and update the IANA allocation rules for type value 5-31. Thanks. Best regards, Jie -Original Message- From: Lou Berger [mailto:lber...@labn.net] Sent: Thursday, February 26, 2015 11:40 AM To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Jie, see below. On 02/25/2015 10:00 PM, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks for your prompt response. Attached is a new revision which reflects your comments and suggestions, please let me know if this revision is OK to progress, thanks. Hi Lou, Thanks for your suggestion. In this new revision the text about valid ERO subobject types is revised a bit, as I noticed the type value of label (3) is also less than 32, while it may not be used to identify a loopback target. Why not? This is a technology specific issue. For example, one could loop a specific lambda in certain optical switches by identifying a specific lambda via a label. Currently the IANA allocation rules for 5-31 is not changed by this revision. If you think this change is needed, I can update the draft before submission. Thanks. I think the previous text should be used. Thanks, Lou Cheers, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, February 26, 2015 2:14 AM To: Dongjie (Jimmy); General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 Hi, Jie. I think we are almost done. There is a proposal for the specific types at the end. Cheers, Elwyn On 25/02/2015 06:10, Dongjie (Jimmy) wrote: 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. Fine. 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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
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
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi, Jie. Thanks for the response. Some notes in line below. Regards, Elwyn On 10/02/2015 03:06, Dongjie (Jimmy) wrote: Hi Elwyn, Thanks a lot for your comments. We will fix the nits with a new revision. And please see my replies inline. Best regards, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Monday, February 09, 2015 7:16 AM To: General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: draft-ietf-teas-rsvp-te-li-lb-03.txt Review Date: 2015/02/08 IETF LC End Date: 2015/02/18 IESG Telechat date: (if known) - Summary: Almost ready with a number of nits. As somebody who has very sketchy knowledge of RSVP-TE and GMPLS, I found the discussion of specification of the identity of the loopback node in an ERO to be very confusing. The phrase strictly identify doesn't really express what is going on to somebody who is not deeply familiar with the topic. An example of the relevant parts of a PATH message might help if that could be managed. What I think is an unfortunate typo (mode instead of node in s3.2) sent me off on a wildgoose chase looking for specifications of loopback modes. I am still not absolutely certain that this *is* a typo! Major issues: None Minor issues: None. Nits/editorial comments: General: For the avoidance of doubt for IANA, it would be desirable to identify the five TBA values as TBA-1 to TBA-5 wherever they occur. General: s/in ADMIN_STATUS/in the ADMIN_STATUS/ (10 cases) Abstract: s/as control plane/for the control plane/ s1, para 1 and last para: s/in Multiprotocol/in the Multiprotocol/ s1,para 2: s/as control plane/for the control plane, s/e.g./e.g.,/ s1, last para: /For MPLS-TP network/For a network supporting MPLS-TP/ s1, last para: Although the formal definitions of LI and LB are given in the 2 RFCs referenced, it would help with the understanding of this draft to add short explanation, such as: ADD: An LSP that is locked, using LI, is prevented from carrying user data traffic. The LB function can only be applied to an LSP that has been previously locked. s2.1: s?the lock/unlock?the lock/unlock status?, s2.1: RFC 3471 calls ADMIN_STATUS Administrative Status. RFC3473 uses ADMIN_STATUS but the two terms are never formally linked together. I suggest: s/in ADMIN_STATUS/in the Administrative Status (ADMIN_STATUS) / s3.1, para 1: Technically, the A bit isn't defined in this draft: Suggest: s/bit defined above/bit used as specified above/ s3.2, para 2: Need to expand acronym: ERO Thanks. The above nits will be fixed in a new revision. 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. s3.2, para 3: the node MUST check that the desired loopback is strictly identified by verifying that the L bit is set to 0 in both the ERO Hop Attributes subobject and the prior subobject. The prior subobject MUST also be checked to ensure that it provides strict identification. What would the prior subobject likely be? Would it be possible to give an example of what the RSVP message would contain in the way of objects and subobjects? This would help with understanding this section. As with the previous comment, the phrase 'strictly identified' is not very clear. Maybe: OLD: desired loopback is strictly identified NEW: node at which loopback is desired is a strict hop in the explicit route OLD: it provides strict identification NEW: it identifies a strict
Re: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
Hi Elwyn, Thanks a lot for your comments. We will fix the nits with a new revision. And please see my replies inline. Best regards, Jie -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Monday, February 09, 2015 7:16 AM To: General area reviewing team Cc: draft-ietf-teas-rsvp-te-li-lb@tools.ietf.org Subject: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: draft-ietf-teas-rsvp-te-li-lb-03.txt Review Date: 2015/02/08 IETF LC End Date: 2015/02/18 IESG Telechat date: (if known) - Summary: Almost ready with a number of nits. As somebody who has very sketchy knowledge of RSVP-TE and GMPLS, I found the discussion of specification of the identity of the loopback node in an ERO to be very confusing. The phrase strictly identify doesn't really express what is going on to somebody who is not deeply familiar with the topic. An example of the relevant parts of a PATH message might help if that could be managed. What I think is an unfortunate typo (mode instead of node in s3.2) sent me off on a wildgoose chase looking for specifications of loopback modes. I am still not absolutely certain that this *is* a typo! Major issues: None Minor issues: None. Nits/editorial comments: General: For the avoidance of doubt for IANA, it would be desirable to identify the five TBA values as TBA-1 to TBA-5 wherever they occur. General: s/in ADMIN_STATUS/in the ADMIN_STATUS/ (10 cases) Abstract: s/as control plane/for the control plane/ s1, para 1 and last para: s/in Multiprotocol/in the Multiprotocol/ s1,para 2: s/as control plane/for the control plane, s/e.g./e.g.,/ s1, last para: /For MPLS-TP network/For a network supporting MPLS-TP/ s1, last para: Although the formal definitions of LI and LB are given in the 2 RFCs referenced, it would help with the understanding of this draft to add short explanation, such as: ADD: An LSP that is locked, using LI, is prevented from carrying user data traffic. The LB function can only be applied to an LSP that has been previously locked. s2.1: s?the lock/unlock?the lock/unlock status?, s2.1: RFC 3471 calls ADMIN_STATUS Administrative Status. RFC3473 uses ADMIN_STATUS but the two terms are never formally linked together. I suggest: s/in ADMIN_STATUS/in the Administrative Status (ADMIN_STATUS) / s3.1, para 1: Technically, the A bit isn't defined in this draft: Suggest: s/bit defined above/bit used as specified above/ s3.2, para 2: Need to expand acronym: ERO Thanks. The above nits will be fixed in a new revision. 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. s3.2, para 3: the node MUST check that the desired loopback is strictly identified by verifying that the L bit is set to 0 in both the ERO Hop Attributes subobject and the prior subobject. The prior subobject MUST also be checked to ensure that it provides strict identification. What would the prior subobject likely be? Would it be possible to give an example of what the RSVP message would contain in the way of objects and subobjects? This would help with understanding this section. As with the previous comment, the phrase 'strictly identified' is not very clear. Maybe: OLD: desired loopback is strictly identified NEW: node at which loopback is desired is a strict hop in the explicit route OLD: it provides strict identification NEW: it identifies a strict hop in the explicit route 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
