Dear All,
We have published a new draft
https://tools.ietf.org/html/draft-lz-lsr-igp-sr-service-segments-00 that
discusses the IGP extensions for SR service segments in SFC.
Comments, suggestions and questions are more than welcome.
Cheers,
YAO
原始邮件
发件人：internet-dra...@ietf.org
Hi Acee,
Thanks for reading the draft.
Yes, the main purpose of this draft is to carry the segment segment information
via IGP so only one node per AS need to be connected with the controller
through BGP-LS.
With the existing BGP-LS extension draft, it is certainly one solution to
configure
Hi Hannes,
Thanks for the correction. My previous description is not accurate.
What I try to say is that, the operator can run either IGP or BGP on the SF
nodes based on the network deployment consideration.
If a network is deployed as shown in the figure below, we can choose to use IGP
to
Hi All,
SR service programming provides a fine integrated solution for overlay and
underlay. Extensions of BGP-LS have already been proposed to advertise service
function information to the controller.
We believe that the all-BGP solution is feasible by configuring BGP sessions
for the BGP-LS
Hi Tony, Hi Les,
Thanks for your thoughts and suggestions.
The per-link RLD will be taken into account regardless of the scope of ERLD-MSD
and the draft will be continuously refined based on the WG's discussion and
conclusion.
Kind Regards,
Yao
Original
From: LesGinsberg(ginsberg)
Hi All,
A new version of draft-liu-lsr-mpls-inspection-msd has just been submitted.
The main changes (compared to the v-01) are:
-The per-link MSD advertisement has been included.
-The name of the new MSD has been changed to RLD MSD to be aligned with the MNA
framework document.
-The
Hi Les,
Thanks a lot for your comments and suggestions.
Generally I think it's reasonable to discuss requirement and the terms first in
the MPLS/SPRING, as well as in the 6MAN WG I suppose, since the requirement is
not SRv6 specific.
Please see my detailed reply in line with [Yao].
Regards,
Dear All，
We've submitted a new draft
https://www.ietf.org/archive/id/draft-liu-lsr-igp-mpd-00.html.
This document proposes the concept of Maximum Packet Depth(MPD) to represent
the packet size that a node is able process from an incoming packet, and the
signaling mechanism for MPD in IGP is
Hi Acee,
Thanks for your comments.
MPD is the maximum packet size that can be processed in the data plane, it's
not the maximum size of MPLS stacks or IPv6 headers that can be supported by a
node.
The reason why MPD is defined separately for MPLS and IPv6 is based on the
consideration that the
Hi All,
A new version of draft-liu-lsr-mpls-inspection-msd has just been uploaded.
In this document, a new type of MSD is defined to reflect the Readable Label
Depth(RLD), which helps in the MPLS MNA solution.
In this version, the main update is that some description is added to explain
why a
Hi Tony,
Thanks a lot for your suggestion. This scenario would be taken into
consideration.
But on the other hand, what I haven't understood is that why ERLD-MSD is
limited to per-node scope considering that each line card may have different
capabilities to read through the label stack.
Hi Les,
Thanks a lot for your review and comments.
This new MSD is a per-node capability just like ERLD-MSD, mainly because it
represents how many MPLS labels the node can read, and it is not related with
the links.
And the description in this draft you mentioned is written taking example by
Hi Gyan,
If I understand you right, in the virtualization scenario, eventually there
would be some way to tell virtual routing instances apart from the routing
protocol's perspective, either they can be treated as different routers with
different router ID (taking OSPF as an example), or
Hi All,
I've posted a new draft
https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-00.html.
This draft defines a new type of MSD, Base MPLS Inspection MSD, and the
mechanism to signal this MSD using IGP and BGP-LS.
The requirement for this MSD mainly comes from MNA, but this
Dear All,
A new draft
https://datatracker.ietf.org/doc/html/draft-liu-lsr-aggregate-header-limit-00
has just been submitted.
This document is a replacement of draft-liu-lsr-igp-mpd as well as
draft-liu-6man-max-header-size.
This document is written to propose extensions for IGP to order to
Hi,
I support the adoption of this draft.
Regards,
Yao___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
to
routing calculations.
This paragraph describes situations where there are other types of device
access, which I think are beyond the scope of IGP and need not be reflected in
this draft.
Would it be better to delete this content?
Best Regards,
Liyan
邮件原文
发件人："liu.yao71"
收件人：lsr
17 matches
Mail list logo
