Subject: [Teas] [Gen-art] Gen-art telechat review of draft-ietf-teas-rsvp-te-li-lb-04.txt (updated)

From: Elwyn Davies <[email-masked]>
Date: Wed, 04 Mar 2015 18:46:28 +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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-teas-rsvp-te-li-lb-04.txt
Reviewer: Elwyn Davies
Review Date: 2015/03/03
IETF LC End Date: 2015/02/18
IESG Telechat date: 20150305

Summary: Almost ready for PS.  I noticed at a late stage in the last 
call reviewing process that the requirement that the hop before a 
loopback node should be a strict hop was unnecessary.  The draft editor, 
Dong Jie, has agreed that this is the case and is checking that the 
removal of this constraint is acceptable to the other authors.  There is 
one other outstanding fix agreed for a nit. Otherwise all my last call 
comments have been cleared.  Thanks.

An additional minor issue about labels has come to light.  See below.

Major issues:
None

Minor issues:
s3.2, para 2, et seq:
The requirement that the hop before the loopback entity MUST be a strict 
hop is unnecessary.  The essential constraint (which is fully specified 
in the -04 draft) is that the entity at which loopback is to occur has 
to be uniquely identified (i.e., it can't be an 'abstract node' 
signifying (potentially) a group of nodes, such as an AS).  I have 
discussed this with Dong Jie, as editor, and he has agreed that the 
constraint is not needed.  A new version of the draft removing the 
constraint is in hand, pending agreement with the other authors and 
checking with the WG.

s3.2:
If dealing with a bidirectional LSP as per RFC 3473, and the ERO 
waypoint (say, an IPv4 address) is qualified with two Label subobjects, 
does loopback put BOTH paths into loopback?  Alternatively, the loopback 
flag could be defined so that it applies to only one of the Labels if 
the ERO Hop attribute subobject is placed after the Label or to both if 
it is placed immediately after the identifying subobject (in this case 
the IPv4 address subobject).

Nits/editorial comments:

s3.2, para 3:
OLD :

    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.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 5 Mar 2015 06:07:18 +0000

Hi Elwyn, 

Thanks for your comments, a new revision -05 was submitted yesterday to solve your comments. 

Regarding the bidirectional LSPs, my understanding is that as specified in this draft, where loopback should be enabled is determined by the ERO subobject prior to the Hop Attribute subobject. So if it is an IP address, the loopback would be enabled on both directions of the bidirectional LSP. If it is a label identifying one direction, then loopback would be enabled for that direction. 

Many thanks,
Jie

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Elwyn Davies
> Sent: Thursday, March 05, 2015 2:46 AM
> To: General area reviewing team; draft-ietf-teas-rsvp-te-li-lb.all; [email-masked]
> Subject: [Teas] [Gen-art] Gen-art telechat review of
> draft-ietf-teas-rsvp-te-li-lb-04.txt (updated)
> 
> 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 wait for direction from your document shepherd or AD before posting a
> new version of the draft.
> 
> Summary: Almost ready for PS.  I noticed at a late stage in the last call
> reviewing process that the requirement that the hop before a loopback node
> should be a strict hop was unnecessary.  The draft editor, Dong Jie, has agreed
> that this is the case and is checking that the removal of this constraint is
> acceptable to the other authors.  There is one other outstanding fix agreed for
> a nit. Otherwise all my last call comments have been cleared.  Thanks.
> 
> The requirement that the hop before the loopback entity MUST be a strict hop is
> unnecessary.  The essential constraint (which is fully specified in the -04 draft)
> is that the entity at which loopback is to occur has to be uniquely identified (i.e.,
> it can't be an 'abstract node'
> signifying (potentially) a group of nodes, such as an AS).  I have discussed this
> with Dong Jie, as editor, and he has agreed that the constraint is not needed.
> A new version of the draft removing the constraint is in hand, pending
> agreement with the other authors and checking with the WG.
> 
> s3.2:
> If dealing with a bidirectional LSP as per RFC 3473, and the ERO waypoint (say,
> an IPv4 address) is qualified with two Label subobjects, does loopback put BOTH
> paths into loopback?  Alternatively, the loopback flag could be defined so that
> it applies to only one of the Labels if the ERO Hop attribute subobject is placed
> after the Label or to both if it is placed immediately after the identifying
> subobject (in this case the IPv4 address subobject).
> 
> Nits/editorial comments:
> 
> s3.2, para 3:
> OLD :
> 
>     less than 32 (i.e., able to identify a specific entity where a loopback can
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 13:53:44 +0200

Jie, Elwyn - Thanks for your review and work addressing the review comments.

Jari

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 05 Mar 2015 12:49:25 +0000

Hi, Jie.

Thanks for the update and changes. Unfortunately we haven't quite 
finished...

The removal of the strict constraint also means it is necessary to 
either change or remove this sentence in the previous paragraph - s3.2, 
para 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 in the
>     Explicit Route Object (ERO) subobject.

As regards the bidirectional LSP story, I think that what you wrote 
below ought to go in the draft.
This is especially true if the changes I suggested for the attribute 
draft are accepted, because it affects how the ERO Hop attributes 
subobject is interpreted - and where it/they should be placed in the list.

Sorry this has turned into such a saga!!

Regards,
Elwyn