Hi Paolo, all,
Thanks for the edits, also the one from the other e-mail. Some responses
to your questions/comments inline:
On Wed 8 Mar 2023, 00:54, Paolo Lucente wrote:
>
> On 16/1/23 13:35, Luuk Hendriks wrote:
> > - If an indexed TLV for a specific NLRI (index > 0) exists alongside a
> > TLV with index 0, does the specific TLV trump the generic one for that
> > NLRI, or does it compliment the generic one?
> > I'd assume the latter.
>
> I'd tend to say that this should not be specified by the tlv draft and
> rather be left as application specific. For example, a path marking or a REL
> draft would specify that.
That's even better, indeed.
> > Sec 4.2
> > - Do we really want the BGP PDU TLV to be possibly preceded by other
> > TLVs? Are there any examples of when this would be useful, other than
> > TLVs containing info needed to correctly parse the BGP PDU (which we
> > should not want anyway in my opinion)?
> > For use cases where one just wants the BGP PDU, being able to bail out
> > as early as possible sounds useful.
> > Or another way to think about this: the BGP PDU TLV is a mandatory TLV
> > for the RouteMonitoring message. To me it makes sense to first list the
> > mandatory TLVs, then the optional ones.
>
> This was the original thinking behind Route Mirroring in RFC7854.
> Hence i wanted to get this new proposal to be consistent to something
> that had already been (successfully) proposed.
Not sure I follow: what do you mean with 'This' here?
> What are the arguments against it?
I just think enforcing the BGP PDU to be the first TLV makes processing
more predictable/consistent. Is that worth sacrificing the flexibility
preceding TLVs would bring? I'd say yes, but I'm very open to be
convinced otherwise.
> > 4.2.1
>
>
> > - do the Group TLVs appear before or after the normal TLVs? If we do
> > enforce sorting by code points, we could steer this behavior by
> > picking a certain code point.
>
> I was not thinking to make Group TLVs somehow special compared to any other
> TLVs that we may define later such that ordering would matter.
Group TLVs introduce new indices that other ('normal') TLVs can point
to, so having the Group TLVs come before the other ones feels like a
'define before use' case to me.
> > - can multiple TLVs point to a Group TLV index? (I assume yes)
>
> Yes. Do you believe text would be needed for this?
It'd be nice to leave as little room for interpretation as possible.
Currently in sec 3 the text states:
Multiple TLVs of the same type and with the same index can be repeated
as part of the same message.
Maybe generalize this to:
Multiple TLVs of the same type and/or with the same (Group) index
can be repeated as part of the same message.
(Though at that point the Group TLV is not yet introduced, so maybe this
is more confusing than it is actually helpful.)
> > - can Group TLV indices appear in the pointed-to indices in another
> > Group TLV, i.e. nested grouping? (I'm not sure this makes things
> > easier for anyone in the end, so if there is no convincing use-case
> > for it, perhaps it should be explicitly forbidden?)
>
> Good one, i agree we could start with explicitely forbidding this and then
> re-visiting if anybody comes with a use-case around it. Added text.
Should we also state the pointed-to-indices can not be 0x0000, simply
because it would not make sense?
> > For my own understanding I created this example RouteMonitoring message
> > (in sort of pseudo-wireformat if you will) comprising:
> > - the usual CommonHeader and PerPeerHeader
> > - the BGP PDU in the first TLV, containing 10 NLRI
> > - two Group TLVs, pointing to four and three actual TLVs, respectively
> > - one TLV pointing to a single NLRI (NLRI number 7)
> > - one TLV pointing to the first Group TLV
> > - one TLV pointing to the second Group TLV
> >
> > RouteMonitoring
> > CommonHeader
> > PerPeerHeader
> > TLVs
> > [type=TBD1, length=x, index=0, value=$BGP_PDU{ NLRI1, .. NLRI10 } ]
> > [type=TBD2, length=x, index=0, value={0x0001, 0x0002, 0x0003, 0x000a}]
> > [type=TBD2, length=x, index=0, value={0x0004, 0x0005, 0x0006}]
> > [type=TBDw, length=x, index=7, value=something_that_applies_to_NLRI7]
> > [type=TBDx, length=x, index=0, value=something_that_applies_to_all]
> > [type=TBDy, length=x, index=0x000b, value=applies_to_four_nlri]
> > [type=TBDz, length=x, index=0x000c, value=applies_to_three_nlri]
> >
> >
> > If this is correctly interpreted and somehow useful for the draft, I'm
> > happy to make this into a proper diagram.
>
> Please, that contribution would be very much appreciated!
Please see
https://github.com/paololucente/draft-ietf-grow-bmp-tlv/pull/3
for a first shot at this. Might need some more love but I wanted to
provide something before the cut-off coming Monday.
> > 4.3
> > Wouldn't it make sense to wrap the BGP PDU in a TLV (for reason codes 1
> > and 3), for the same reasons we want to wrap the PDU in RouteMonitoring
> > messages?
>
> Good point and, again as i may have already stated, my purpose was to try to
> be consistent to what already exists.
Fair point. Perhaps this is something to keep in mind for the -bis then.
> Text was added in commit
> https://github.com/paololucente/draft-ietf-grow-bmp-tlv/commit/0278888e2c615d63b72ac7a851b6efabfb03c932
> . Just let me know any additions / deletions / changes. Otherwise these are
> good to go for upcomign -11 revision!
Thanks!
luuk
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
