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:[email protected]]
Sent: Thursday, February 26, 2015 11:40 AM
To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team
Cc: [email protected]
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:[email protected]]
Sent: Thursday, February 26, 2015 2:14 AM
To: Dongjie (Jimmy); General area reviewing team
Cc: [email protected]
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, 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 verified to be
less than 32, and for type values 1 and 2 the prefix length MUST
be
32 and 128 respectively.
It would be better to use the names of the types (1 = IPv4, 2 =
IPv6) that would make it clearer why the lengths are as they are
specified.
Is it possible to explain why the type has to be less than this
apparently arbitrary limit of 32? And hence what allocation
constraints ought to be applied in the future - this might need a
change in the IANA allocation rules that should be specified in
this
document.
The limit of 32 was to ensure the subobject type can identify a
specific node
or interface. Maybe we can specify the required types (node,
interface) explicitly to make it clear.
That would help.
It has just occurred to me why you want to say that the prefix
lengths are
32/128 bits - so that the IP address refers to exactly one node.
However this is possibly confusing because RFC 3209 *requires* the
values to be 32/128 respectively and the subobjects do carry just a
host address and not a domain prefix as might be implied by lower values.
As specified in 4.3.3 of RFC 3209, for the ERO subobjects, the
prefix lengths
are not required to be just 32/128. While as specified in 4.4.1 of
RFC 3209, for the RRO subobjects, the prefix lengths are required to be
32/128.
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
(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:
- 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.
[1]
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml
#r
svp-
parameters-25
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
