Re: [Isis-wg] Mail regarding draft-ietf-isis-l2bundles

[Shraddha Hegde <[e-mail]>]

Les,

Pls see inline...

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Wednesday, May 11, 2016 12:56 PM
To: Shraddha Hegde <[e-mail]>; [e-mail]
Cc: [e-mail] list <[e-mail]>
Subject: RE: Mail regarding draft-ietf-isis-l2bundles

Shraddha -

From: Shraddha Hegde [mailto:[e-mail]]
Sent: Tuesday, May 10, 2016 8:34 PM
To: Les Ginsberg (ginsberg); [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> list
Subject: RE: Mail regarding draft-ietf-isis-l2bundles

Les,

Pls see inline..

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Tuesday, May 10, 2016 10:16 PM
To: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> list <[e-mail]<mailto:[e-mail]>>
Subject: RE: Mail regarding draft-ietf-isis-l2bundles

Shraddha -

From: Shraddha Hegde [mailto:[e-mail]]
Sent: Tuesday, May 10, 2016 6:31 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> list
Subject: Mail regarding draft-ietf-isis-l2bundles

Authors,

I have a few generic comments on the draft.


-          The draft needs an "elements of procedure" section that talks about when the new TLV gets originated/updated/purged

[Les:] What is being advertised are attributes of L2 bundle member links which comprise an L3 interface on which IS-IS has an adjacency. This is quite comparable to link attributes advertised for the parent L3 link as defined in RFC 5305. Note that an equivalent "elements of procedures" section does not exist in that document. Other than saying the advertisements follow the state of the L2 bundle member I am not sure what such a section would say.
Is it really unclear as to when the advertisements would be sent/withdrawn?

<Shraddha> What would happen if one of the member links is flapping continuously? Would this TLV be updated
                        That frequently?
                       When is the TLV 25 generated? Only when the corresponding L3 link is up?
                      There are possibilities that the LAG interface is down even if some members in the LAG are up. What
                     Should be the behavior in that case?
                    If an operator wants to use this extension for OAM purposes, how will he know which of the member links
                    really have a problem when the parent L3 link itself does not appear?
                   What would happen to the adj-sids if a member link is flapping? Would the sids change? Remain same? Or
                   This draft wants the implementors to make their own choices?

                    Whatever choices you want to make for the above scenarios, it needs to be spelt out clearly in the document.
                   Detailed and unambiguous specs will only help the implementations to be healthy and easily interoperable.

[Les2:] TLV 25 requires inclusion of the information about the parent L3 adjacency - the "Parent L3 Neighbor Descriptor" specified in Section 2. If the parent adjacency is NOT UP then we do not have that information available and so TLV 25 cannot be advertised for any of the L2 bundle member links. As regards the L2 Bundle members, we are - as always - advertising information about links which can carry traffic i.e., when advertised  they are operationally and administratively up. (We aren't simply advertising a list of links attached to the router).

<Shraddha> Which section of the draft talks about adding member links which are operational and UP?
If it doesn't exist can you add that statement to the draft?

In this regard the behavior is no different than what is done for advertising link attributes on the L3 links(RFC 5305).  I am not aware of any confusion in regards to RFC 5305 on the equivalent points you raise - so not clear to me why you think more needs to be said in this draft.

<Shraddha> Member links are certainly different category of attributes in comparison with the ones defined in RFC5305. How is adding more clarifications going to harm the document?

Identification of the member links is done by "L2 Bundle Member Link Local Identifiers" as defined in Section 2.

Whether adj-sids are preserved across a link flap is a local implementation issue.
<Shraddha> Can you add that statement to the draft?

I think the draft could benefit from a discussion of rapid flapping - we will add some text in that regard.



-          Section 2.2 talks about shared attributes sub-tlv. It's not clear why the  sub-tlvs  defined for tlv 22/222 needs to be added/duplicated

In TLV 25. For ex: link bandwidth sub TLV will be part of tlv 22 so what is the specific need to add it in TLV25 as well?

What would be the behavior if the contents of sub-tlvs from 22 and 25 do not match?



[Les:] The sub-TLVs advertised in TLV 22 describe the L3 link - which is the composite of the L2 bundle members. The advertisements which are defined in this document describe individual bundle members. There is no intent to compare attributes advertised for L2 bundle members with attributes advertised for the L3 link.



<Shraddha> Excerpts from section 2.2

"
   All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23,
   141, 222, and 223 registry are in the category of shared attribute
   sub-TLVs unless otherwise specified in this document."

Does above statement mean that all the sub-tlvs that appear in TLV 22 might appear in
TLV 25?
There are many sub-tlvs for ex 24,25,26 etc for which it is not clear why they would need
To appear in TLV 25. If there is no such need and use-case, it is better to pick only the
Sub-tlvs which are meaningful for member links.



[Les2:] Section 4 specifies for each sub-TLV type whether it is allowed in TLV 25 or not.



<Shraddha> Suggest to change the above paragraph as below.



"  All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23,
   141, 222, and 223 registry are in the category of shared attribute
   sub-TLVs except the ones specified in section 4 of this document."







If there are no specific use cases, it's better to omit this section (In the interest of reducing implementation complexity)

and add it later in a new draft whenever such a use case arises.



[Les:] Sorry, I do not know to what section this comment should be applied.

<Shraddha> I meant the contents from section 2.2 as specified above.



[Les2:] Section 2.2 is an essential piece of the description of the TLV/sub-TLV encoding. It cannot be omitted.



      Les



   Les





Rgds

Shraddha