Xiaohu,
please see inline:
On 6/16/14 04:58 , Xuxiaohu wrote:
Hi Peter,
Please see my response inline
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Friday, June 13, 2014 8:31 PM
To: Xuxiaohu; [email protected] list; OSPF List
Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2
extensions for SR
Hi Xiaohu,
please see inline:
On 6/13/14 12:09 , Xuxiaohu wrote:
Hi peter,
-----Original Message-----
From: Isis-wg [mailto:[email protected]] On Behalf Of Peter
Psenak
Sent: Friday, June 13, 2014 4:32 PM
To: Xuxiaohu; [email protected] list; OSPF List
Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2
extensions for SR
Xiaohu,
please see inline:
On 6/13/14 09:51 , Xuxiaohu wrote:
Hi all,
There are some encoding inconsistencies between OSPFv2 extensions
and ISIS
extensions for SR as follows:
1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP
reachability
advertisement. In OSPF-SR, the prefix-sid advertisement is
piggybacked on OSPF Extended Prefix LSA which is used to advertise
other attributes associated with the prefix, rather than the
reachability. IMHO, the OSPF encoding is more flexible since the
label distribution and the reachability advertisement are
independent. As a result, the route summary on area boundaries at
least can be enabled as before. Besides, the prefix-SID sub-TLV can
be used to advertise a range of prefix/SID pairs (see item2). In
fact, ISIS allows us to do the same way as OSPF with a much lower
cost (see section 3 of
http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of course, it
seems that you co-authors prefer to the piggyback way.
OSPF LSAs that are used to advertise the prefixex are not extensible,
so we had to define a new LSA for the purpose of advertising a prefix related
attributes.
ISIS is different, as they can add sub-TLVs to existing TLVs.
I see. For ISIS, you use the piggyback way (piggyback the label/sid
advertisement on the reachability advertisement messages). For OSPFv2, you
have no way to use the piggyback way anymore, so you defined a new LSA...
That's why I said you prefer to the piggyback way. However, I don't think the
piggyback way is much worthwhile from the perspective of flexibility and
extensibility.
2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise
an SID for a
single prefix. And it relays on the SID/Label Binding TLV to
advertise a range of prefix/SID pairs. In contrast, In OSPF-SR, the
prefix-sid sub-TLV can be used to specify a range of addresses and
their associated Prefix SIDs. By the way, in the 4.3. SID/Label
Binding sub-TLV. it has the following text: "Range Size: usage is the
same as described in Section 4.2." Did you co-authors want to propose
two ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to achieve
the same goal (i..e, advertise a range of prefix/SID pairs)?
because in OSPF advertisement of the prefix SID is decoupled from the
advertisement of prefix reachability, we can afford to advertise the
range of SIDs in the prefix-SID sub-TLV as such.
IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be
decoupled from the prefix reachability advertisement as well:)
in OSPFv3 case, we have a way to advertise the prefix using the proposed
encoding in draft-acee-ospfv3-lsa-extend, but do not advertise the reachability
of the prefix - it's call NU-bit (rfc5340, A.4.1.1.)
That's great. BTW, don't you believe the ISIS protocol has provided almost the
same capability as the NU-bit (see the following text quoted from RFC5305)?
correct, max-metric means unreachable in ISIS.
"...If a prefix is advertised
with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph
3.0), this prefix MUST NOT be considered during the normal SPF
computation. This allows advertisement of a prefix for purposes
other than building the normal IP routing table...".
No, we do not define two ways to achieve the same thing. Binding TLV
is used for a different purpose and the same usage is only applicable
to the Range semantics, not to the whole Binding TLV.
Does that mean the Binding sub-TLV in the OSPF-SR could not be used to
advertise a range of prefix/sid pairs while the binding sub-TLV in the ISIS-SR
could?
Binding TLV in OSPF is only used to advertise a "LSP path" local to the
advertising
router, it's not used for anything else. YOu can still advertise a single "LSP
path"
for range of prefixes.
Don't you believe it's better for the Binding TLV in ISIS to be used to
advertise a LSP as well?
Binding TLV in ISIS can be used to advertise "LSP path" as well as SRMS
mappings.
In ISIS, due to the need to decouple prefix reachability from SID advertisement,
Binding TLV is used for SR Mapping Server (SRMS) adevrtisement on top of what
it is used in OSPF (in OSPF SRMS advertisements are using the Prefix/SID
sub-TLV).
To decouple prefix reachability from SID advertisement, why not consider the
approach of using the MAX_PATH_METRIC trick (see section 3 of
http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00)?
it's a matter of choice. Authors of ISIS draft choose the cleaner way IMHO.
regards,
Peter
Best regards,
Xiaohu
6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID
field since the
MT-ID field is already contained in the parent TLV of the prefix-SID
sub-TLV. In OSPF, the MT-ID field is contained in the Prefix SID
Sub-TLV since the parent TLV of the prefix-sid sub-TLV doesn't
contain that MT-ID field. IMHO, it's better to contain the MT-ID in
the parent prefix-specific TLV of the prefix-SID sub-TLV. In other
words, why not contain the MT-ID in the OSPF Extended Prefix TLV,
instead of the prefix-sid sub-TLV (see section 3 of
http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)?
no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV.
The reason is that attributes are MT specific, not the prefix itself - e.g.
you may want to advertise different metrics for the same prefix in
different topologies, not the same prefix twice.
Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV?
no, we don't want to end up with sub-sub-TLVs right from the beginning.
regards,
Peter
Best regards,
Xiaohu
regards,
Peter
Anyway, although it is unavoidable for us to define extensions to
both ISIS and
OSPF for the same thing due to the fact that both protocols have been
widely used, could we try our best to keep the encodings of ISIS and
OSPF as consistent as possible for the same functionality? In this
way, once someone has read the ISIS extension draft, he or she can
easily think of what has been done in the OSPF extension draft accordingly,
and vice verse.
Best regards,
Xiaohu
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
.
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
.
.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
