Re: [Teas] AD review of draft-ietf-teas-lsp-attribute-ro

[Lou Berger <[e-mail]>]

[ccamp dropped response doesn't concern the WSON draft]
On 1/21/2015 6:57 AM, Adrian Farrel wrote:
>> For draft-ietf-teas-rsvp-te-li-lb this could be (restricting the TLV to
>> > explicit nodes, precluding link ids):
>> > The Attribute Flags TLV with Loopback Attribute Flag set MUST be present
>> > after an explicit Hop addressing an TE Router ID identifying a specific
>> > node or a Link ID identifying an incoming TE link.  it MUST NOT be present
>> > after a loose,  abstract node, Link ID identifying an outgoing TE link,
>> > Component Interface ID or Label.
> Ah, joy!
> Yes. This needs another fix to draft-ietf-teas-rsvp-te-li-lb.
> I've made a note in the data tracker and marked that I-D as needing a new
> revision.
>
I think this phrasing is too restrictive as it may be possible to put
some of the identified items into loopback in some technologies, e.g.,
an output interface.  How about:

after:
    The mechanism defined in [I-D.ietf-teas-lsp-attribute-ro] is used to
address the loopback request
     to the particular node.
add:
     The ingress MUST ensure that the desired  loopback mode is strictly
identified in the ERO.
and
OLD:

   If the bit is set, the node SHOULD try to put the LSP into loopback mode.
NEW
    If the bit is set, 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.
    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.
    If the desired loopback is not strictly identified the request MUST
be ignored
    and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated.

     Otherwise, the node SHOULD try to put the LSP into loopback mode.


Lou