Subject: [Gen-art] Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03

From: Elwyn Davies <[email-masked]>
Date: Sun, 08 Feb 2015 23:16:09 +0000

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

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.

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.

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

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.

s5: In line with "modern" policy, the discussion in para 3 of s5 of 
draft-ietf-teas-lsp-attribute-ro-01 could be thought of a "Privacy 
Considerations" rather than strictly Security Considerations. Please 
consider separating out a privacy discussion and referencing the 
discussion in draft-ietf-teas-lsp-attribute-ro-01 (which should in turn 
talk about Privacy Considerations).

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 10 Feb 2015 03:06:24 +0000

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:[email-masked]]
> Sent: Monday, February 09, 2015 7:16 AM
> To: General area reviewing team
> Cc: [email-masked]
> 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
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> Document:
> 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.
> 
> 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.
> 

Thanks. The above nits will be fixed in a new revision.

> 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"

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? 

> 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".

> 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:

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.

> 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.

> Considerations" rather than strictly Security Considerations. Please consider
> separating out a privacy discussion and referencing the discussion in
> draft-ietf-teas-lsp-attribute-ro-01 (which should in turn talk about Privacy
> Considerations).

OK

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 18 Feb 2015 19:44:15 +0000

Hi, Jie.

Thanks for the response.

Some notes in line  below.

Regards,
Elwyn

> 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.

> 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.

> 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.

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.

[1] 
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml#rsvp-parameters-25

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 25 Feb 2015 06:10:43 +0000

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.
> >>
> >> "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"
> > 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.
> >
> >> 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.
> 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).
> >
> 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
> 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.
> 
> 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
> 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.

> >> 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
> 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".

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 25 Feb 2015 18:13:53 +0000

Hi, Jie.

I think we are almost done.

There is a proposal for the specific types at the end.

Cheers,
Elwyn

> Agree with this description. Will update in the new revision.
Fine.
> 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 thin…
I will negotiate with the authors of draft-ietf-teas-lsp-attribute-ro to 
see if we can agree a revision.
> 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…
You are right:  I missed that RRO and ERO were different.  So specifying 
the prefix lengths is indeed needed as you say.
> 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 len…
That would certainly cover the situation as it is at the moment.  I 
can't immediately think of any new types that might be added and would 
be relevant as loopback points, but you might have some ideas on this.  
I was trying to think of an easy way to factor this into the IANA 
registration process but I can't see anything very simple. I think a few 
'weasel words' will do for an unlikely event.  How about:
NEW mk 3:
The prior subobject MUST be able to identify a specific node or 
interface, specifically, at the time of writing, it can be one of the 
following:
   - Type "IPv4 prefix" with prefix length 32,
   - Type "IPv6 prefix" with prefix length 128, or
   - Type "Unnumbered Interface ID".
If any new subobject types are defined in future and they identify a 
specific node or interface, the
specification of the new type can extend this list.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 26 Feb 2015 03:00:28 +0000

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

> Sent: Thursday, February 26, 2015 2:14 AM
> To: Dongjie (Jimmy); General area reviewing team
> Subject: Re: Gen-art LC review of draft-ietf-teas-rsvp-te-li-lb-03
> 
> Hi, Jie.
> 
> >>>> "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"
> >> 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.
> >>>> 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".
> >> 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.
> >> 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
> >> 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
> >> 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.
> >>
> >> 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
> > 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:
> >>>> 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.
> >> or interface. Maybe we can specify the required types (node,
> >> interface) explicitly to make it clear.
> >> That would help.
> >> 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.
> You are right:  I missed that RRO and ERO were different.  So specifying the
> prefix lengths is indeed needed as you say.
> >
> >> (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".
> That would certainly cover the situation as it is at the moment.  I can't
> immediately think of any new types that might be added and would be relevant
> as loopback points, but you might have some ideas on this.
> I was trying to think of an easy way to factor this into the IANA registration
> process but I can't see anything very simple. I think a few 'weasel words' will do
> for an unlikely event.  How about:
> NEW mk 3:
> The prior subobject MUST be able to identify a specific node or interface,
> specifically, at the time of writing, it can be one of the
> following:
> If any new subobject types are defined in future and they identify a specific
> node or interface, the specification of the new type can extend this list.
> 
> 
> >> [1]
> >> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml#r
> >> svp-
> >> parameters-25

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 Feb 2015 22:39:35 -0500

Jie,
see below.

> 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 targ…
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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 26 Feb 2015 06:15:45 +0000

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

> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, February 26, 2015 11:40 AM
> To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team
> > 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,
> >
> > 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.
> >
> 
> >>>>>> 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.
> >>>> 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.
> >>>> 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.
> >>>> 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
> >>>> 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
> >>>> 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.
> >>>>
> >>>> 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
> >>>> 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
> >> we would only specify that the L bit in the prior ERO subobject MUST
> >> be set to 0 in the new revision.
> >> OK.
> >>>
> >> 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:
> >>>>>> change in the IANA allocation rules that should be specified in
> >>>>>> this
> >> document.
> >> 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.
> >> You are right:  I missed that RRO and ERO were different.  So
> >> specifying the prefix lengths is indeed needed as you say.
> >>>
> >>>> 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
> >>>> right boundary.  Perhaps this means that you need to define an
> >>>> update to the allocation rules for the registry so that values
> >>>> below (say)
> >> 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.
> >>>
> >>> 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".
> >> can't immediately think of any new types that might be added and
> >> would be relevant as loopback points, but you might have some ideas on
> this.
> >> registration process but I can't see anything very simple. I think a
> >> few 'weasel words' will do for an unlikely event.  How about:
> >> NEW mk 3:
> >> specific node or interface, the specification of the new type can extend this
> list.
> >>
> >>
> >>>> [1]

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 26 Feb 2015 13:07:12 +0000

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

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 27 Feb 2015 02:40:14 +0000

Hi Elwyn, 

Thanks a lot for your comments, these typos are fixed and the new revision has been submitted.

Best regards,
Jie

> Sent: Thursday, February 26, 2015 9:07 PM
> To: Dongjie (Jimmy); Lou Berger; General area reviewing team
> I checked through the updated draft (-04) that you sent out.  That all looks fine
> except for a couple of typos:
> 
> 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
> 
> > 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
> >
> >> your comments and suggestions, please let me know if this revision is
> >> OK to progress, thanks.
> >>> Hi Lou,
> >>>
> >> 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.
> >>
> >>>>>>>>        The ingress MUST ensure that the desired loopback mode
> >>>>>>>> is strictly identified in the ERO.
> >>>>>>>>
> >>>>>>> If you agree with the above change, in your suggestion we can
> >>>>>>> also substitute
> >>>>>> "node" with "entity".
> >>>>>> have the L bit set to 0 to ensure that the two subobjects
> >>>>>> together strictly specify a
> >>>>>> 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
> >>>>>> Thus as standardized currently, EROs aren't allowed any other
> >>>>>> sort of subobject
> >>>>>> draft-ietf-teas-lsp-attribute-ro-01 updates the presence rules
> >>>>>> for RROs to allow for the RRO Hop Attributes subobjects but the
> >>>>>> 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.
> >>>>>>
> >>>>>> The L bit is only set in the type subobject if it is a loose hop
> >>>>>> so the check should
> >>>> be
> >>>>>> clearer in the lock draft that there can be multiple Hop
> >>>>>> Attribute subobjects after the type subobject.
> >>>>>>
> >>>>>> I hope this helps.
> >>>> we would only specify that the L bit in the prior ERO subobject
> >>>> MUST be set to 0 in the new revision.
> >>>> OK.
> >>>> 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:
> >>>>>>>>>       less than 32, and for type values 1 and 2 the prefix
> >>>>>>>>> length MUST
> >> be
> >>>>>>>>>       32 and 128 respectively.
> >>>>>>>> IPv6) that would make it clearer why the lengths are as they
> >>>>>>>> are
> >> specified.
> >>>>>>>> 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.
> >>>>>> 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.
> >>>> subobject, making such update to IANA was not our original
> >>>> intention, also requires discussion with ADs and TEAS chairs.
> >>>> 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".
> >>>> registration process but I can't see anything very simple. I think
> >>>> a few 'weasel words' will do for an unlikely event.  How about:
> >>>> NEW mk 3:
> >>>> If any new subobject types are defined in future and they identify
> >>>> a specific node or interface, the specification of the new type can
> >>>> extend this
> >> list.
> >>>>
> >>>>>> [1]
> >>>>>> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.x
> >>>>>> ml
> >>>>>> #r
> >>>>>> svp-
> >>>>>> parameters-25

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 28 Feb 2015 17:59:34 +0000

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:
> With the added IANA consideration that you have been discussing with 
> Lou we should be all done.
>
>> 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
>>
>>> could loop a

---

From: Lou Berger <[email-masked]>
Date: Sat, 28 Feb 2015 13:27:31 -0500

Elwyn,

Thanks for the comments.  I think your new text is fine. (And not 
materially different than the current text.)

Lou