Nitin:
Thanks for responding
[snip]
>
>[Sue]: Yes, not all forms would benefit. However, MPLS does have the
>stack tags that we may want to save and match on. Also: the 5-tuples
>may be a part of matching some routes. By using rt-form, we are using
>the TLV format to set-up these multiple formats. Each format, would
>have the appropriate expectations for the appropriate address families.
>
>[Sue]: I think it provides table based code.
[Nitin] The main issue is that the grammar will not be deterministic.
[Nitin] In other words, one needs a way to specify that <route-tag-1>
<rt-form-A> is valid and <route-tag-1> <rt-form-B> is NOT valid.
[Sue-2 on]
Why is the grammar not explicit? Let's put the type back in for each
<match_form = DST> <match_type = IPv4> <ip-v4-prefix> (addresses are just
a specific type of prefix)
<match_form=SRC> <match_type = IPv4> <ipv4-prefix> (addresses are
just a specific type of prefix)
<match_form=DST-SRC> <match_type = ipv4> <ipv4-prefix> <ipv4-prefix>
This is TLV where (form-type) implies a specific length (in example, 8,8,
16).
If you want to go with the traditional TLV form, consider the (form-type) as
a Type field,
And put in a length field.
The same is true of the nh-form and nh-type fields
<rt-form = NH-Name>> <NH-name> - this is the only valid
<rt-form = NH-Address> <NH-type = v4> <ip-v4-prefix> (note address is just
a specific type of prefix)
<rt-form=NH-address><NH-type=v6> <ip-v6-prefix> (note that prefix is just a
specific type of prefix)
I did change these directly to TLV forms - so there would be a stepping
stone to the
>
>The <ip-route-type> will need to be associated specifically with
><ipv4-route> and <ipv6-route>.
>
>[Sue]: yes, it could. With the rt-form and the rib-family type,
>perhaps we can remove the rt-type.
>[snip]
Rib-family-type and route-type are kind of the same thing. I need to think
if there is a case where they can be different...
[Sue-2-off]
[snip]
>>5) Why did you specify differently?
[Nitin]:: Unicast multiple next hops are covered in Section 7.2.3.
<snip>
[Nitin] LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to
indicate ECMP/load-balancing
> and multicast replication next hops.
[Nintin] Section 7.3 talks about multicast replication (and refers to
Section 7.2.2).
[Sue]: You are stating that:
<nexthop-list> ::= (<nexthop> <LOAD_BALANCE_WEIGHT>) [(<nexthop>
<LOAD_BALANCE_WEIGHT>)... ]
Is the flag for NH ECMP
<nexthop-list> ::= (<nexthop> <PROTECTION_PREFERENCE>)
[(<nexthop> <PROTECTION_PREFERENCE>)... ]
Sets primary/backup, and mixed with LOAD_BALANCE_WEIGHT - you groupings of
next-hops that are used for multicast (as default).
<nexthop-list> ::= <nexthop> [ <nexthop> ... ]
This makes it specific, but requires you specify the LOAD_BALANCE_WEIGHT
with each next hoip.
Were you intended your LOAD_BALANCE_WEIGHT to be a integer, and the
LOAD_PROTECTION_PREFERENCE to be a number.
Thanks
Nitin
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
