Subject: Re: [mpls] MPLS-RT review of [email-masked]

From: Lizhong Jin<[email-masked]>
Date: Tue, 4 Sep 2012 09:47:53 +0800

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)" <[email-masked]> 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 system B 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: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Dutta, Pranjal K (Pranjal)
> Sent: Friday, August 31, 2012 10:22 AM
> To: Lizhong Jin
> Cc: [email-masked]; [email-masked]; draft-pdutta-mpls-
> [email-masked]
> Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> [email-masked]
> 
> Hi Lizhong,
>                         Please refer my answers inline.
> Thanks,
> Pranjal
> 
> 
> From: Lizhong Jin [mailto:[email-masked]] 
> Sent: Thursday, August 30, 2012 11:42 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: [email-masked]; mpls@ietf.
> org; [email-masked]
> Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> [email-masked]
> 
> 
> 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)" <[email-masked]> 
> 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 <[email-masked]> 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, is it 
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: 
[email-masked]
> > > Sr Strategy and Standards Manager            [email-masked]
> > > Ericsson Inc                          phone: +46 10 717 52 13
> > >                                               +46 767 72 92 13
> > >

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 4 Sep 2012 08:07:25 +0530

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.

“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.

Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, September 03, 2012 6:48 PM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; [email-masked]; [email-masked]; Dutta, Pranjal K (Pranjal)
Subject: RE: [mpls] MPLS-RT review of [email-masked]

Hi Pranjal,
Much clear now, thank you. Two inline comments that maybe missed in your previous email.

Thanks
Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 2012/09/01 01:38:39:

> because the FEC-Label mapping database continue to exist in system B in same
> > > Note to authors: You have been CC’d on this email so that you can know
> > > Reviews should comment on whether the document is coherent, is it 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
> > > secretary, and CC’d to the MPLS WG email list. If necessary, comments
> > > Loa Andersson                         email: [email-masked]

---

From: Lizhong Jin<[email-masked]>
Date: Tue, 4 Sep 2012 11:53:03 +0800

Hi Pranjal,

> [Pranjal] The multiple instances are within VRF. Sure, will clarify 
[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?

> 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

> org; [email-masked]; Dutta, Pranjal K (Pranjal)
> wrote 2012/09/01 01:38:39:
> 
> > Hi Lizhong, 

> > because the FEC-Label mapping database continue to exist in systemB in 
same 
know
> > > > Reviews should comment on whether the document is coherent, isit 
useful
and is
whether
comments

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Tue, 4 Sep 2012 18:26:26 +0530

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] 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.

Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, September 03, 2012 8:53 PM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] MPLS-RT review of [email-masked]

Hi Pranjal,

> [Pranjal] The multiple instances are within VRF. Sure, will clarify
[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?

> 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

> > because the FEC-Label mapping database continue to exist in systemB in same
> > > > Reviews should comment on whether the document is coherent, isit useful

---

From: Lizhong Jin<[email-masked]>
Date: Thu, 6 Sep 2012 22:33:35 +0800

Hi Pranjal,
See inline below. Thanks.

Lizhong

2012/09/04 20:56:26:

> [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 
> 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.

> [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? 
> 
> > 
> [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 
> > 
> > 
> > 

whether
comments

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 7 Sep 2012 00:43:31 +0530

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

Sent: Thursday, September 06, 2012 7:34 AM

Hi Pranjal,

Lizhong

"Dutta, Pranjal K (Pranjal)" <[email-masked]> wrote 2012/09/04 20:56:26:

> independent LDP stack. We are not saying that “don’t use different LSR-ID

> upon and an application may find utility if it is known that a set
[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.