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

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 2 Mar 2015 03:17:57 +0000

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:[email-masked]]
> Sent: Sunday, March 01, 2015 2:28 AM
> To: Elwyn Davies; Dongjie (Jimmy); General area reviewing team
> Cc: [email-masked]
> 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 <[email-masked]>
> 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:[email-masked]]
> > >>> Sent: Thursday, February 26, 2015 11:40 AM
> > >>> To: Dongjie (Jimmy); Elwyn Davies; General area reviewing team
> > >>> Cc: [email-masked]
> > >>> 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-masked]]
> > >>>>> Sent: Thursday, February 26, 2015 2:14 AM
> > >>>>> To: Dongjie (Jimmy); General area reviewing team
> > >>>>> Cc: [email-masked]
> > >>>>> 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-parameter
> > >>>>>>> s.xml
> > >>>>>>> #r
> > >>>>>>> svp-
> > >>>>>>> parameters-25
> > >
> >
> >
>