[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org
From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta () alcatel-lucent ! com>
Date: 2012-09-06 19:25:31
Message-ID: C584046466ED224CA92C1BC3313B963E13F0E03C6A () INBANSXCHMBSA3 ! in ! alcatel-lucent ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
Hi Lizhong,
I think we are back to square one.
※there are two points. 1. then could I say the loop detection could be done without \
Node-ID TLV? As pointed out in my previous email, the loop detection could be simply \
done by the FEC set checking. 2. if we are agreed with the first point, then we could \
discuss other utility for Node-ID TLV.§
+---------------------------+
FEC Type A--------| APP X |------------------FEC Type B
(session 1) +---------------------------+ (session 2)
There is an Application X (APP X) that uses LDP for \
signaling its required infrastructure and can work in mix mode 每 means it can stitch \
LSPs between FEC Type A (exchanged over session 1) and FEC Type B (exchanged over \
session 2) thru its ※own FIB§. If both session 1 and 2 are || to same node then may \
impact the functioning of APP X.
Such example could be H-VPLS (RFC 4762) where FEC Type A = \
spoke PW = FEC128 and FEC Type B = mesh PW = FEC129. It is also possible that \
FEC-Type B = mLdp FEC where the entire tree is dedicated for VPLS Mcast in mesh \
points (means no upstream PW Label).
There could be other examples, such as MS-PW where you may \
stitch FEC128-FEC129 from aggregation->core.
Thanks,
Pranjal
________________________________
From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Thursday, September 06, 2012 7:34 AM
To: Dutta, Pranjal K (Pranjal)
Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.org; \
mpls-chairs@tools.ietf.org
Subject: RE: [mpls] MPLS-RT review of \
draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org
Hi Pranjal,
See inline below. Thanks.
Lizhong
"Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> wrote 2012/09/04 \
20:56:26:
> Hi Lizhong,
>
> Pls. refer inline to your questions.
>
> [Lizhong] to confirm I understand correctly. Do you mean the
> multiple instances in this draft does not include the VRF case? And
> multiple instances are belong to only one VRF, right?
>
> Doesn＊t each VRF uses its own LSR-ID/Router-ID today? Each VRF is an
> independent LDP stack. We are not saying that ※don＊t use different LSR-ID
> across VRFs§. The draft brings the case for multiple LSR within a
> VRF which is not the case today.
[Lizhong] clear now, thanks.
>
> [Lizhong] If peer does not support FEC capability, you should have
> some local configuration to indicate the FEC set. Then you could
> still avoid loop by this local indication. I am trying to see the
> technical motivation of Node-ID TLV. If we only want to know the
> same peering relationship for easy management, the NMS could simply
> do that. Is there any other technical reason for Node-ID TLV?
>
> Node-ID TLV is not limited to loop detection in FEC exchanges. By
> configuration/NMS we can do many things 每 even static MPLS
> without needing LDP or signaling at all (e.g We shouldn＊t have
> notion of ※ldp discovery§). Since the context of this draft is a
> signaling protocol, so
> Node-ID TLV serves as an indication for || sessions. Inclusion of
> Node ID TLV is optional and is not mandatory as mentioned in the
> draft. Sessions are
> part of infrastructure based on which various applications are built
> upon and an application may find utility if it is known that a set
> of sessions are ||
> to same node.
[Lizhong] there are two points. 1. then could I say the loop detection could be done \
without Node-ID TLV? As pointed out in my previous email, the loop detection could be \
simply done by the FEC set checking. 2. if we are agreed with the first point, then \
we could discuss other utility for Node-ID TLV.
>
> Thanks,
> Pranjal
>
> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> Sent: Monday, September 03, 2012 8:53 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.
> org; mpls-chairs@tools.ietf.org
> Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> instance@tools.ietf.org
>
>
> Hi Pranjal,
>
> > Hi Lizhong,
> >
> > ※Then does the LDP multiple instance in this draft does not
> > include the VRF case? It is better to explicit describe this,
> > otherwise it is confusing. In the VRF case, the FEC will be
> > duplicated between different instances.§
> >
> > [Pranjal] The multiple instances are within VRF. Sure, will clarify
> > explicitly.
> [Lizhong] to confirm I understand correctly. Do you mean the
> multiple instances in this draft does not include the VRF case? And
> multiple instances are belong to only one VRF, right?
>
> >
> > ※If the FEC set (identified by capability) is totally
> > disjoint between two instance, it could be simply discard the FEC
> > label mapping if not match capability to avoid loop, why we still
> > need Node-ID TLVˋ§
> >
> > [Pranjal] Node-ID TLV is a generic construct and not associated with FEC
> > capability. If peer hasn＊t implemented FEC capability then you may need
> > some way to figure out. Secondly, even though peer supports FEC capability,
> > it is useful to know that we are running || sessions to same peering system.
> [Lizhong] If peer does not support FEC capability, you should have
> some local configuration to indicate the FEC set. Then you could
> still avoid loop by this local indication. I am trying to see the
> technical motivation of Node-ID TLV. If we only want to know the
> same peering relationship for easy management, the NMS could simply
> do that. Is there any other technical reason for Node-ID TLV?
>
> Thanks
> Lizhong
>
> >
> > Thanks,
> > Pranjal
> >
> >
> >
> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> > Sent: Monday, September 03, 2012 6:48 PM
> > To: Dutta, Pranjal K (Pranjal)
> > Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.
> > org; mpls-chairs@tools.ietf.org; Dutta, Pranjal K (Pranjal)
> > Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> > instance@tools.ietf.org
> >
> >
> > Hi Pranjal,
> > Much clear now, thank you. Two inline comments that maybe missed in
> > your previous email.
> >
> > snip from previous email...
> > > 2. For LDP multiple instance, is it allowed for duplicated FEC
> > > between two instance?
> > >
> > > [Pranjal] Duplicated FECs won＊t be allowed. The parallel sessions
> > > between two peering systems needs to be disjoint with respect to the
> > > working set
> > > 每 the FECs. This needs to be ensured thru various FEC specific
> > > session capabilities. Each || session must advertise disjoint FEC
> > > capabilities. Section
> > > 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep
> > > the FEC distribution mutually exclusive. What criteria to be used
> > > for segregation
> > > of FECs are to be decided on case to case basic. This draft provides
> > > the fundamental building block for control plane fate separation.
> > [Lizhong] Then does the LDP multiple instance in this draft does not
> > include the VRF case? It is better to explicit describe this,
> > otherwise it is confusing. In the VRF case, the FEC will be
> > duplicated between different instances.
> >
> > >
> > > 3. If duplicated FECs are possible between two instance, receiving
> > > same label mapping from parallel multi-lsr peering sessions could
> > > not interpret as loop, right?
> > >
> > > [Pranjal] Duplicated FECs are not allowed across . But what if a
> > > peering system misbehaves or peering system not supporting the
> > > solution (thus agnostic
> > > Of the fact that a few sessions are terminated in same peering
> > > system) leaks FECs on all || sessions? That may result in a loop for
> > > some applications
> > > and ※Section 3. Detection of multi-instance peering§ addresses that
> > > issue. It lets a system aware of || sessions and thus can take
> > > necessary actions.
> > [Lizhong] If the FEC set (identified by capability) is totally
> > disjoint between two instance, it could be simply discard the FEC
> > label mapping if not match capability to avoid loop, why we still
> > need Node-ID TLVˋ
> >
> > Thanks
> > Lizhong
> >
> >
> > "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
> > wrote 2012/09/01 01:38:39:
> >
> > > Hi Lizhong,
> > > I think I didn＊t clarify on 每 ※Do you mean the
> > > two instance need to synchronize FEC mapping information§. The
> > > multi-instance peering that we described about
> > > Is a little different from multi-instance IGPs. In multi-instance
> > > LDP case by default the FEC database would be shared in the sense
> > > that all label mapping would share the same
> > > global label space and thus following is possible/desirable.
> > >
> > > System A
> > > System B System C
> > > LSR-A1----------------------------LSR-
> > > B1 X LSR-B3--------------------------LSR-C1
> > > LSR-A2 ---------------------------LSR-
> > > B2 X LSR-B4--------------------------LSR-C2
> > >
> > >
> > > There can be a seamless LSP/Tunnel between
> > > System A and System C for FEC F1. C->B label mapping L1 is exchanged
> > > using B3-C1 LSR tuples and
> > > B->A label mapping L2 is exchanged using B2-A2 LSR tuples. This is
> > > because the FEC-Label mapping database continue to exist in
> systemB in same
> > > way as it does today. There would be only one FEC F1 in the LIB :
> > >
> > >
> > > F1 --> egress label L1 (Local LSR B3---Remote LSR C1)
> > > -角
> > > ingress label L2 (Local LSR B2---Remote LSR A2)
> > >
> > > The X connect at system B is L1->L2
> > >
> > >
> > >
> > > Thanks,
> > > Pranjal
> > >
> > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> > > Dutta, Pranjal K (Pranjal)
> > > Sent: Friday, August 31, 2012 10:22 AM
> > > To: Lizhong Jin
> > > Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-pdutta-mpls-
> > > multi-ldp-instance@tools.ietf.org
> > > Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> > > instance@tools.ietf.org
> > >
> > > Hi Lizhong,
> > > Please refer my answers inline.
> > > Thanks,
> > > Pranjal
> > >
> > >
> > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> > > Sent: Thursday, August 30, 2012 11:42 PM
> > > To: Dutta, Pranjal K (Pranjal)
> > > Cc: draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org; mpls@ietf.
> > > org; mpls-chairs@tools.ietf.org
> > > Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> > > instance@tools.ietf.org
> > >
> > >
> > > Hi Pranjal,
> > > Thanks for the clarification, much clear than before for me now.
> > > Please see inline for addtional comments.
> > >
> > > One more question for section 3.
> > > "When a LSR receives a FEC label mapping from a peering session but
> > > same FEC mapping has been already receiver over another peering
> > > session associated with same Node-ID then the receiving LSR MUST
> > > send a Label Release to the peering session with statuc code"
> > > How a LSR could know the FEC mapping information from another
> > > instance? Do you mean the two instance need to synchronize FEC
> > > mapping information?
> > >
> > > [Pranjal] One way to think is as follows 每 let＊s say that detection
> > > of multi-instance peering is implemented as in Section 3. Then
> > > receiving system would know about the sessions terminating
> > > in same remote peering system. So the receiving system can create a
> > > group/bundle id internally for all such || sessions and keep the
> > > FEC-label mappings also in the database. If there is a
> > > collision of Fec label mappings in the group-id database then label
> > > release can be sent, keeping the first one intact.
> > >
> > >
> > > Thanks
> > > Lizhong
> > >
> > > "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
> > > wrote 2012/08/31 01:00:53:
> > >
> > > > 2. For LDP multiple instance, is it allowed for duplicated FEC
> > > > between two instance?
> > > >
> > > > [Pranjal] Duplicated FECs won＊t be allowed. The parallel sessions
> > > > between two peering systems needs to be disjoint with respect to the
> > > > working set
> > > > 每 the FECs. This needs to be ensured thru various FEC specific
> > > > session capabilities. Each || session must advertise disjoint FEC
> > > > capabilities. Section
> > > > 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep
> > > > the FEC distribution mutually exclusive. What criteria to be used
> > > > for segregation
> > > > of FECs are to be decided on case to case basic. This draft provides
> > > > the fundamental building block for control plane fate separation.
> > > [Lizhong] Then does the LDP multiple instance in this draft does not
> > > include the VRF case? It is better to explicit describe this,
> > > otherwise it is confusing. In the VRF case, the FEC will be
> > > duplicated between different instances.
> > >
> > > >
> > > > 3. If duplicated FECs are possible between two instance, receiving
> > > > same label mapping from parallel multi-lsr peering sessions could
> > > > not interpret as loop, right?
> > > >
> > > > [Pranjal] Duplicated FECs are not allowed across . But what if a
> > > > peering system misbehaves or peering system not supporting the
> > > > solution (thus agnostic
> > > > Of the fact that a few sessions are terminated in same peering
> > > > system) leaks FECs on all || sessions? That may result in a loop for
> > > > some applications
> > > > and ※Section 3. Detection of multi-instance peering§ addresses that
> > > > issue. It lets a system aware of || sessions and thus can take
> > > > necessary actions.
> > > [Lizhong] If the FEC set (identified by capability) is totally
> > > disjoint between two instance, it could be simply discard the FEC
> > > label mapping if not match capability to avoid loop, why we still
> > > need Node-ID TLVˋ
> > >
> > > >
> > > > 4. In case 1~4, one interface will serve multiple instance, I guess,
> > > > the interface you refer is physical interface, and when sharing one
> > > > physical interface, then one sub-interface for each instance is
> > > > still required, right? In my understanding, one IP interface could
> > > > not be shared by multiple LDP instance, otherwise how to treat the
> > > > prefix of that interface.
> > >
> > > > [Pranjal] I won＊t view it as sub-interface since all instances are
> > > > running in same FEC database. So if we think from a ※virtual router§
> > > > point of view (each
> > > > Virtual Router is separated across all verticals in RIB/LFIB/FIB and
> > > > self-sufficient) then all the multiple LSR instances would be
> > > > running within same
> > > > Virtual Router and thus can share interfaces assigned to that
> > > > Virtual Router. Although the draft does not prevent usage of same
> > > > Interface across all LSRs
> > > > in practice it is desirable to fate separate the physical topology
> > > > to achieve separation across entire vertical. Separation of physical
> > > > topology can be
> > > > achieved by LDP Multi-topology that synchronizes IGP and LDP＊s view (
> > > > http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or
> > > > by using hello
> > > > adjacency capabilities at LDP level (http://tools.ietf.
> > > > org/html/draft-pdutta-mpls-ldp-adj-capability-00).
> > > >
> > > >
> > > > Hope to see your clarification. Thanks.
> > > >
> > > > Lizhong
> > > >
> > > >
> > > > Loa Andersson <loa@pi.nu> wrote 2012/08/29 17:10:01:
> > > >
> > > > > Kamran. Eric and Lizhong,
> > > > >
> > > > > You have been selected as an MPLS Review team reviewers for
> > > > > draft-pdutta-mpls-multi-ldp-instance-00.txt.
> > > > >
> > > > > Note to authors: You have been CC＊d on this email so that you can know
> > > > > that this review is going on. However, please do not review your own
> > > > > document.
> > > > >
> > > > > Reviews should comment on whether the document is coherent,
> isit useful
> > > > > (ie, is it likely to be actually useful in operational
> networks), and is
> > > > > the document technically sound? We are interested in knowing whether
> > > > > the document is ready to be considered for WG adoption (ie, it doesn＊t
> > > > > have to be perfect at this point, but should be a good start).
> > > > >
> > > > > Reviews should be sent to the document authors, WG co-chairs and
> > > > > secretary, and CC＊d to the MPLS WG email list. If necessary, comments
> > > > > may be sent privately to only the WG chairs.
> > > > >
> > > > > Are you able to review this draft by Sep 13, 2012?
> > > > >
> > > > > Thanks, Loa
> > > > > (as MPLS WG chair)
> > > > > --
> > > > >
> > > > >
> > > > > Loa Andersson email: loa.
> andersson@ericsson.com
> > > > > Sr Strategy and Standards Manager loa@pi.nu
> > > > > Ericsson Inc phone: +46 10 717 52 13
> > > > > +46 767 72 92 13
> > > > >
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:st1="urn:schemas-microsoft-com:office:smarttags" \
xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=gb2312">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:sans-serif;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"\@SimSun";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:SimSun;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Lizhong,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> & \
nbsp;
I think we are back to square one.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>※</span></font><font size=2
face=sans-serif><span style='font-size:10.0pt;font-family:sans-serif'>there are
two points. 1. then could I say the loop detection could be done without
Node-ID TLV? As pointed out in my previous email, the loop detection could be
simply done by the FEC set checking. 2. if we are agreed with the first point,
then we could discuss other utility for Node-ID TLV.</span></font><font
face="Times New Roman"><span style='font-family:"Times New \
Roman"'>§</span></font><o:p></o:p></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>
+---------------------------+ \
<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> FEC Type \
A--------| APP X \
|------------------FEC
Type B<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> (session \
1) \
+---------------------------+ (session \
2)<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> & \
nbsp;
<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> & \
nbsp; \
There is an Application X (APP X) that uses LDP for signaling its required \
infrastructure and can work in mix mode 每 means it can stitch <br> LSPs between FEC \
Type A (exchanged over session 1) and FEC Type B (exchanged over session 2) thru its \
※own FIB§. If both session 1 and 2 are || to same <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>node then may impact the functioning of APP \
X.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>
Such example could be H-VPLS (RFC 4762) where FEC Type A = spoke PW
= FEC128 and FEC Type B = mesh PW = FEC129. It is <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> also possible that FEC-Type B = mLdp FEC where the
entire tree is dedicated for VPLS Mcast in mesh points (means no upstream PW
Label). <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>
There could be other examples, such as MS-PW where you may stitch FEC128-FEC129
from aggregation->core. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>
<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Pranjal<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> & \
nbsp;
<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face=SimSun><span style='font-size:12.0pt'>
<hr size=3 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Lizhong Jin
[mailto:lizhong.jin@zte.com.cn] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, September 06, 2012
7:34 AM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName \
w:st="on">draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org</st1:PersonName>; \
<st1:PersonName w:st="on">mpls@ietf.org</st1:PersonName>; <st1:PersonName \
w:st="on">mpls-chairs@tools.ietf.org</st1:PersonName><br> <b><span \
style='font-weight:bold'>Subject:</span></b> RE: [mpls] MPLS-RT review of \
<st1:PersonName w:st="on">draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org</st1:PersonName></span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face=SimSun><span \
style='font-size:12.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=3 face=SimSun><span style='font-size:12.0pt'><br>
</span></font><font size=2 face=sans-serif><span style='font-size:10.0pt;
font-family:sans-serif'>Hi Pranjal,</span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>See inline below. \
Thanks.</span></font> <br> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>Lizhong</span></font> <br>
<font size=1 face=sans-serif><span \
style='font-size:7.5pt;font-family:sans-serif'> </span></font> <br>
<br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>"<st1:PersonName \
w:st="on">Dutta, Pranjal K</st1:PersonName> (Pranjal)" \
<pranjal.dutta@alcatel-lucent.com> wrote 2012/09/04 20:56:26:<br> <br>
> Hi Lizhong,</span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> </span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> \
Pls. refer inline to your \
questions.</span></font> <br> <font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> \
</span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> [Lizhong] to confirm I \
understand correctly. Do you mean the <br> > multiple instances in this draft does \
not include the VRF case? And <br> > multiple instances are belong to only one \
VRF, right?</span></font> <br> <font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> </span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> Doesn＊t each VRF uses its own \
LSR-ID/Router-ID today? Each VRF is an<br> > independent LDP stack. We are not \
saying that ※don＊t use different LSR-ID </span></font><br> <font size=2 \
face=sans-serif><span style='font-size:10.0pt;font-family:sans-serif'>> across \
VRFs§. The draft brings the case for multiple LSR within a <br> > VRF which is \
not the case today. </span></font> <br> <font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>[Lizhong] clear now, \
thanks.</span></font> <br> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> </span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> [Lizhong] If peer does not \
support FEC capability, you should have <br> > some local configuration to \
indicate the FEC set. Then you could <br> > still avoid loop by this local \
indication. I am trying to see the <br> > technical motivation of Node-ID TLV. If \
we only want to know the <br> > same peering relationship for easy management, the \
NMS could simply <br> > do that. Is there any other technical reason for Node-ID \
TLV? </span></font><br> <font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> </span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> Node-ID TLV is not limited to \
loop detection in FEC exchanges. By <br> > configuration/NMS we can do many things \
每 even static MPLS </span></font><br> <font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> without needing LDP or signaling \
at all (e.g We shouldn＊t have <br> > notion of ※ldp discovery§). Since the \
context of this draft is a <br> > signaling protocol, so </span></font><br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> Node-ID TLV serves as an \
indication for || sessions. Inclusion of <br> > Node ID TLV is optional and is not \
mandatory as mentioned in the <br> > draft. Sessions are </span></font><br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> part of infrastructure based on \
which various applications are built<br> > upon and an application may find \
utility if it is known that a set <br> > of sessions are ||</span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> to same node.</span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>[Lizhong] there are two points. 1. \
then could I say the loop detection could be done without Node-ID TLV? As pointed out \
in my previous email, the loop detection could be simply done by the FEC set \
checking. 2. if we are agreed with the first point, then we could discuss other \
utility for Node-ID TLV.</span></font> <br>
<br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> </span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> Thanks,</span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> Pranjal<br>
</span></font><br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> <br>
> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] <br>
> Sent: Monday, September 03, 2012 8:53 PM<br>
> To: <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName> (Pranjal)<br>
> Cc: <st1:PersonName \
w:st="on">draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org</st1:PersonName>; \
mpls@ietf.<br> > org; <st1:PersonName \
w:st="on">mpls-chairs@tools.ietf.org</st1:PersonName><br> > Subject: RE: [mpls] \
MPLS-RT review of draft-pdutta-mpls-multi-ldp-<br> > \
instance@tools.ietf.org</span></font> <br> <font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> </span></font> <br>
<font size=2 face=sans-serif><span \
style='font-size:10.0pt;font-family:sans-serif'>> <br>
> Hi Pranjal, <br>
> <br>
> > Hi Lizhong, <br>
> > <br>
> > ※Then does the LDP multiple instance in this draft does not <br>
> > include the VRF case? It is better to explicit describe this, <br>
> > otherwise it is confusing. In the VRF case, the FEC will be <br>
> > duplicated between different instances.§ <br>
> > <br>
> > [Pranjal] The multiple instances are within VRF. Sure, will clarify <br>
> > explicitly. <br>
> [Lizhong] to confirm I understand correctly. Do you mean the <br>
> multiple instances in this draft does not include the VRF case? And <br>
> multiple instances are belong to only one VRF, right? <br>
> <br>
> > <br>
> > ※If the FEC set (identified by capability) is totally <br>
> > disjoint between two instance, it could be simply discard the FEC <br>
> > label mapping if not match capability to avoid loop, why we still <br>
> > need Node-ID TLV</span></font><font size=2><span lang=ZH-CN
style='font-size:10.0pt'>ˋ</span></font><font size=2 face=sans-serif><span
style='font-size:10.0pt;font-family:sans-serif'>§ <br>
> > <br>
> > [Pranjal] Node-ID TLV is a generic construct and not associated with
FEC <br>
> > capability. If peer hasn＊t implemented FEC capability then you may
need <br>
> > some way to figure out. Secondly, even though peer supports FEC
capability,<br>
> > it is useful to know that we are running || sessions to same peering
system.<br>
> [Lizhong] If peer does not support FEC capability, you should have <br>
> some local configuration to indicate the FEC set. Then you could <br>
> still avoid loop by this local indication. I am trying to see the <br>
> technical motivation of Node-ID TLV. If we only want to know the <br>
> same peering relationship for easy management, the NMS could simply <br>
> do that. Is there any other technical reason for Node-ID TLV? <br>
> <br>
> Thanks <br>
> Lizhong <br>
> <br>
> > <br>
> > Thanks, <br>
> > Pranjal <br>
> > <br>
> > <br>
> > <br>
> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] <br>
> > Sent: Monday, September 03, 2012 6:48 PM<br>
> > To: <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
> > Cc: <st1:PersonName \
w:st="on">draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org</st1:PersonName>; \
mpls@ietf.<br> > > org; <st1:PersonName \
w:st="on">mpls-chairs@tools.ietf.org</st1:PersonName>; <st1:PersonName \
w:st="on">Dutta, Pranjal K</st1:PersonName> (Pranjal)<br> > > Subject: RE: \
[mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-<br> > > \
instance@tools.ietf.org <br> > > <br>
> > <br>
> > Hi Pranjal, <br>
> > Much clear now, thank you. Two inline comments that maybe missed in <br>
> > your previous email. <br>
> > <br>
> > snip from previous email... <br>
> > > 2. For LDP multiple instance, is it allowed for duplicated FEC <br>
> > > between two instance? <br>
> > > <br>
> > > [Pranjal] Duplicated FECs won＊t be allowed. The parallel
sessions <br>
> > > between two peering systems needs to be disjoint with respect to
the <br>
> > > working set <br>
> > > 每 the FECs. This needs to be ensured thru various FEC specific <br>
> > > session capabilities. Each || session must advertise disjoint
FEC <br>
> > > capabilities. Section <br>
> > > 2.1.1 explains the use of LDP session capabilities (RFC5561) to
keep <br>
> > > the FEC distribution mutually exclusive. What criteria to be
used <br>
> > > for segregation <br>
> > > of FECs are to be decided on case to case basic. This draft
provides <br>
> > > the fundamental building block for control plane fate
separation. <br>
> > [Lizhong] Then does the LDP multiple instance in this draft does not <br>
> > include the VRF case? It is better to explicit describe this, <br>
> > otherwise it is confusing. In the VRF case, the FEC will be <br>
> > duplicated between different instances. <br>
> > <br>
> > > <br>
> > > 3. If duplicated FECs are possible between two instance,
receiving <br>
> > > same label mapping from parallel multi-lsr peering sessions
could <br>
> > > not interpret as loop, right? <br>
> > > <br>
> > > [Pranjal] Duplicated FECs are not allowed across . But what if a
<br>
> > > peering system misbehaves or peering system not supporting the <br>
> > > solution (thus agnostic <br>
> > > Of the fact that a few sessions are terminated in same peering <br>
> > > system) leaks FECs on all || sessions? That may result in a loop
for <br>
> > > some applications <br>
> > > and ※Section 3. Detection of multi-instance peering§ addresses
that <br>
> > > issue. It lets a system aware of || sessions and thus can
take <br>
> > > necessary actions. <br>
> > [Lizhong] If the FEC set (identified by capability) is totally <br>
> > disjoint between two instance, it could be simply discard the FEC <br>
> > label mapping if not match capability to avoid loop, why we still <br>
> > need Node-ID TLV</span></font><font size=2><span lang=ZH-CN
style='font-size:10.0pt'>ˋ</span></font><font size=2 face=sans-serif><span
style='font-size:10.0pt;font-family:sans-serif'> <br>
> > <br>
> > Thanks <br>
> > Lizhong <br>
> > <br>
> > <br>
> > "<st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)" <pranjal.dutta@alcatel-lucent.com> <br>
> > wrote 2012/09/01 01:38:39:<br>
> > <br>
> > > Hi Lizhong, <br>
> > >
I think I didn＊t clarify on 每 ※Do you mean the <br>
> > > two instance need to synchronize FEC mapping information§. The <br>
> > > multi-instance peering that we described about <br>
> > > Is a little different from multi-instance IGPs. In
multi-instance <br>
> > > LDP case by default the FEC database would be shared in the
sense <br>
> > > that all label mapping would share the same <br>
> > > global label space and thus following is possible/desirable. <br>
> > > <br>
> > >
System A
<br>
> > > System B
System C <br>
> > >
LSR-A1----------------------------LSR-<br>
> > > B1 X LSR-B3--------------------------LSR-C1
<br>
> > >
LSR-A2 ---------------------------LSR-<br>
> > > B2 X LSR-B4--------------------------LSR-C2
<br>
> > > <br>
> > > <br>
> > >
There can be a seamless LSP/Tunnel between <br>
> > > System A and System C for FEC F1. C->B label mapping L1 is
exchanged<br>
> > > using B3-C1 LSR tuples and <br>
> > > B->A label mapping L2 is exchanged using B2-A2 LSR tuples.
This is <br>
> > > because the FEC-Label mapping database continue to exist in <br>
> systemB in same <br>
> > > way as it does today. There would be only one FEC F1 in the LIB
> <br>
> > > <br>
> > >
<br>
> > > F1 --> egress label L1 (Local LSR B3---Remote LSR C1) <br>
> > >
-角<br>
> > > ingress label L2 (Local LSR B2---Remote LSR A2) <br>
> > > <br>
> > >
The X connect at system B is L1->L2 <br>
> > >
<br>
> > > <br>
> > > <br>
> > > Thanks, <br>
> > > Pranjal <br>
> > > <br>
> > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On
Behalf Of <br>
> > > <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
> > > Sent: Friday, August 31, 2012 10:22 AM<br>
> > > To: Lizhong Jin<br>
> > > Cc: <st1:PersonName w:st="on">mpls@ietf.org</st1:PersonName>; \
<st1:PersonName w:st="on">mpls-chairs@tools.ietf.org</st1:PersonName>; \
draft-pdutta-mpls-<br> > > > multi-ldp-instance@tools.ietf.org<br>
> > > Subject: Re: [mpls] MPLS-RT review of
draft-pdutta-mpls-multi-ldp-<br>
> > > instance@tools.ietf.org <br>
> > > <br>
> > > Hi Lizhong, <br>
> > >
Please refer my answers inline. <br>
> > > Thanks, <br>
> > > Pranjal <br>
> > > <br>
> > > <br>
> > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] <br>
> > > Sent: Thursday, August 30, 2012 11:42 PM<br>
> > > To: <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
> > > Cc: <st1:PersonName \
w:st="on">draft-pdutta-mpls-multi-ldp-instance@tools.ietf.org</st1:PersonName>; \
mpls@ietf.<br> > > > org; <st1:PersonName \
w:st="on">mpls-chairs@tools.ietf.org</st1:PersonName><br> > > > Subject: RE: \
[mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-<br>
> > > instance@tools.ietf.org <br>
> > > <br>
> > > <br>
> > > Hi Pranjal, <br>
> > > Thanks for the clarification, much clear than before for me now.
<br>
> > > Please see inline for addtional comments. <br>
> > > <br>
> > > One more question for section 3. <br>
> > > "When a LSR receives a FEC label mapping from a peering session
but <br>
> > > same FEC mapping has been already receiver over another peering <br>
> > > session associated with same Node-ID then the receiving LSR MUST
<br>
> > > send a Label Release to the peering session with statuc
code" <br>
> > > How a LSR could know the FEC mapping information from another <br>
> > > instance? Do you mean the two instance need to synchronize FEC <br>
> > > mapping information? <br>
> > > <br>
> > > [Pranjal] One way to think is as follows 每 let＊s say that
detection<br>
> > > of multi-instance peering is implemented as in Section 3. Then <br>
> > > receiving system would know about the sessions terminating <br>
> > > in same remote peering system. So the receiving system can
create a <br>
> > > group/bundle id internally for all such || sessions and keep the
<br>
> > > FEC-label mappings also in the database. If there is a <br>
> > > collision of Fec label mappings in the group-id database then
label <br>
> > > release can be sent, keeping the first one intact. <br>
> > > <br>
> > > <br>
> > > Thanks <br>
> > > Lizhong <br>
> > > <br>
> > > "<st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)" <pranjal.dutta@alcatel-lucent.com> <br>
> > > wrote 2012/08/31 01:00:53:<br>
> > > <br>
> > > > 2. For LDP multiple instance, is it allowed for duplicated
FEC <br>
> > > > between two instance? <br>
> > > > <br>
> > > > [Pranjal] Duplicated FECs won＊t be allowed. The parallel
sessions <br>
> > > > between two peering systems needs to be disjoint with
respect to the<br>
> > > > working set <br>
> > > > 每 the FECs. This needs to be ensured thru various FEC
specific <br>
> > > > session capabilities. Each || session must advertise disjoint
FEC <br>
> > > > capabilities. Section <br>
> > > > 2.1.1 explains the use of LDP session capabilities
(RFC5561) to keep<br>
> > > > the FEC distribution mutually exclusive. What criteria to
be used <br>
> > > > for segregation <br>
> > > > of FECs are to be decided on case to case basic. This draft
provides<br>
> > > > the fundamental building block for control plane fate
separation. <br>
> > > [Lizhong] Then does the LDP multiple instance in this draft does
not<br>
> > > include the VRF case? It is better to explicit describe this, <br>
> > > otherwise it is confusing. In the VRF case, the FEC will be <br>
> > > duplicated between different instances. <br>
> > > <br>
> > > > <br>
> > > > 3. If duplicated FECs are possible between two instance,
receiving <br>
> > > > same label mapping from parallel multi-lsr peering sessions
could <br>
> > > > not interpret as loop, right? <br>
> > > > <br>
> > > > [Pranjal] Duplicated FECs are not allowed across . But what
if a <br>
> > > > peering system misbehaves or peering system not supporting
the <br>
> > > > solution (thus agnostic <br>
> > > > Of the fact that a few sessions are terminated in same
peering <br>
> > > > system) leaks FECs on all || sessions? That may result in a
loop for<br>
> > > > some applications <br>
> > > > and ※Section 3. Detection of multi-instance peering§
addresses that <br>
> > > > issue. It lets a system aware of || sessions and thus
can take <br>
> > > > necessary actions. <br>
> > > [Lizhong] If the FEC set (identified by capability) is totally <br>
> > > disjoint between two instance, it could be simply discard the
FEC <br>
> > > label mapping if not match capability to avoid loop, why we
still <br>
> > > need Node-ID TLV</span></font><font size=2><span lang=ZH-CN
style='font-size:10.0pt'>ˋ</span></font><font size=2 face=sans-serif><span
style='font-size:10.0pt;font-family:sans-serif'> <br>
> > > <br>
> > > > <br>
> > > > 4. In case 1~4, one interface will serve multiple instance,
I guess,<br>
> > > > the interface you refer is physical interface, and when
sharing one <br>
> > > > physical interface, then one sub-interface for each
instance is <br>
> > > > still required, right? In my understanding, one IP
interface could <br>
> > > > not be shared by multiple LDP instance, otherwise how to
treat the <br>
> > > > prefix of that interface. <br>
> > > <br>
> > > > [Pranjal] I won＊t view it as sub-interface since all
instances are <br>
> > > > running in same FEC database. So if we think from a
※virtual router§<br>
> > > > point of view (each <br>
> > > > Virtual Router is separated across all verticals in RIB/LFIB/FIB
and<br>
> > > > self-sufficient) then all the multiple LSR instances would
be <br>
> > > > running within same <br>
> > > > Virtual Router and thus can share interfaces assigned to
that <br>
> > > > Virtual Router. Although the draft does not prevent usage
of same <br>
> > > > Interface across all LSRs <br>
> > > > in practice it is desirable to fate separate the physical
topology <br>
> > > > to achieve separation across entire vertical. Separation of
physical<br>
> > > > topology can be <br>
> > > > achieved by LDP Multi-topology that synchronizes IGP and
LDP＊s view (<br>
> > > >
http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or<br>
> > > > by using hello <br>
> > > > adjacency capabilities at LDP level (http://tools.ietf.<br>
> > > > org/html/draft-pdutta-mpls-ldp-adj-capability-00). <br>
> > > > <br>
> > > > <br>
> > > > Hope to see your clarification. Thanks. <br>
> > > > <br>
> > > > Lizhong <br>
> > > > <br>
> > > > <br>
> > > > <st1:PersonName w:st="on">Loa Andersson</st1:PersonName>
<loa@pi.nu> wrote 2012/08/29 17:10:01:<br>
> > > > <br>
> > > > > Kamran. Eric and Lizhong,<br>
> > > > > <br>
> > > > > You have been selected as an MPLS Review team
reviewers for<br>
> > > > > draft-pdutta-mpls-multi-ldp-instance-00.txt.<br>
> > > > > <br>
> > > > > Note to authors: You have been CC＊d on this email so
that you can know<br>
> > > > > that this review is going on. However, please do not
review your own<br>
> > > > > document.<br>
> > > > > <br>
> > > > > Reviews should comment on whether the document is
coherent, <br>
> isit useful<br>
> > > > > (ie, is it likely to be actually useful in operational
<br>
> networks), and is<br>
> > > > > the document technically sound? We are
interested in knowing whether<br>
> > > > > the document is ready to be considered for WG adoption
(ie, it doesn＊t<br>
> > > > > have to be perfect at this point, but should be a good
start).<br>
> > > > > <br>
> > > > > Reviews should be sent to the document authors, WG
co-chairs and<br>
> > > > > secretary, and CC＊d to the MPLS WG email list. If
necessary, comments<br>
> > > > > may be sent privately to only the WG chairs.<br>
> > > > > <br>
> > > > > Are you able to review this draft by Sep 13, 2012?<br>
> > > > > <br>
> > > > > Thanks, Loa<br>
> > > > > (as MPLS WG chair)<br>
> > > > > -- <br>
> > > > > <br>
> > > > > <br>
> > > > > <st1:PersonName w:st="on">Loa Andersson</st1:PersonName>
email: loa.<br>
> andersson@ericsson.com<br>
> > > > > Sr Strategy and Standards Manager
loa@pi.nu<br>
> > > > > Ericsson Inc
phone: +46 10 717 52 13<br>
> > > > >
+46 767 72 92 13<br>
> > > > > </span></font><o:p></o:p></p>
</div>
</body>
</html>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--===============5590156341983315094==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic