George Swallow | 1 Jun 17:59 2006
Picon

Time to set the agenda

Please forward your agenda requests to Loa and me.  Include the amount
of time that you'd like.

Thanks,

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

benjamin.niven-jenkins | 2 Jun 16:04 2006

RE: Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

Adrian,

Adrian Farrel <mailto:adrian <at> olddog.co.uk> wrote:
> Please review, comment, implement (!) and tell us what we have done
> wrong. 

A couple of comments:

Section 4.1, bullet 1 states "P2MP Tunnel table (mplsP2mpTunnelTable)
that sparse augments the MPLS-TE Tunnel table".  I'm not exactly sure
what "sparse augments" means.

Section 4.2, second paragraph - "When an MPLS-TE tunnel is a P2MP
tunnel, certain objects in the mplsTunnelTable are have new meanings",
remove the extraneous "are".

Section 6, states "The nature of P2MP tunnels is such that an LSR that
is crossed by a tunnel may either be the ingress of that tunnel or have
precisely one upstream LSP segment (also known as in-segment [RFC3812])
for that LSP." and "A single P2MP cross-connect has zero or one
in-segment."

draft-ietf-mpls-rsvp-te section 18.1.1 states "There are two approaches
to dealing with re-merge case.  In the first, the node detecting the
re-merge case, i.e., the re-merge node, allows the re-merge case to
persist but data from all but one incoming interface is dropped at the
re-merge node." and "When configured to allow a re-merge case to
persist, the re-merge node receives data associated with the P2MP LSP on
multiple incoming interfaces, but it may only send the data from one of
these interfaces to its outgoing interfaces, i.e., the node MUST drop
(Continue reading)

Srinivas Reddy | 5 Jun 22:47 2006
Picon

problem configurating tunnel using mplsadm2 and iproute2

Hi,

  I am using linux-2.4.19 kernel. I am not able to configure tunnel between two linux machines.Please fins the details given below.
eth0                                         eth1
   LSR1(eth1)<-------->(eth0)LSR2

tunnel starts at LSR1 and ends at LSR2.

LSR1 configuration:

[root <at> impls utils]#ifconfig
eth0      Link encap:Ethernet  HWaddr 00:03:47:E2:D8:83 
          inet addr:10.1.5.139  Bcast:10.1.5.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2543202 errors:0 dropped:0 overruns:2 frame:0
          TX packets:5065 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:197998558 (188.8 Mb)  TX bytes:224558 (219.2 Kb)
          Interrupt:22 Base address:0x9000

eth1      Link encap:Ethernet  HWaddr 00:03:47:E1:A3:D7 
          inet addr:10.1.6.139  Bcast:10.1.6.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:486 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1926 (1.8 Kb)  TX bytes:48158 (47.0 Kb)
          Interrupt:17 Base address:0xb000

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:63 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6443 (6.2 Kb)  TX bytes:6443 (6.2 Kb)

mpls0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:192.168.0.2  P-t-P:192.168.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1492  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:541 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:45444 (44.3 Kb)

Commands used to configure LSR1:

[root <at> impls utils]# ./mplsadm2 -L eth1:1
Label Space: Success

[root <at> impls utils]# ./mplsadm2 -A -O 1 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Key: 0x00000002
Out Segment add: Success
Out Instr: Illegal seek

[root <at> impls utils]# ./mplsadm2 -D -O 1 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Out Segment del: No such process
Out Instr: No such process
[root <at> impls utils]# cat /proc/net/mpls_out
0x00000002 0/0/0 1 PUSH(gen 1024) SET(eth1,192.168.0.1)
[root <at> impls utils]# ./mplsadm2 -D -O 0x00000002
Out Segment del: Success
[root <at> impls utils]#

[root <at> impls utils]# ./mplsadm2 -A -O 0 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Key: 0x00000003
Out Segment add: Success
Out Instr: Illegal seek
[root <at> impls utils]# ./mplsadm2 -D -O 0x00000003
Out Segment del: Success
[root <at> impls utils]#

[root <at> impls utils]# ./mplsadm2 -A -O 0
Key: 0x00000004
Out Segment add: Success
[root <at> impls utils]# ./mplsadm2 -D -O 0x00000004
Out Segment del: Success

[root <at> impls utils]# ./mplsadm2 -O 0x00000005 -o
push:gen:1024:set:eth1:ipv4:192.168.0.1
Out Instr: Success
[root <at> impls utils]# ./mplsadm2 -A -T mpls0
[root <at> impls utils]# route add default dev mpls0

[root <at> impls utils]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.5.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.1.6.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 mpls0
0.0.0.0         10.1.6.140      0.0.0.0         UG    0      0        0 eth1

[root <at> impls utils]#
[root <at> impls utils]# ./mplsadm2 -A -O 1
Key: 0x00000006
Out Segment add: Success
[root <at> impls utils]# ./mplsadm2 -B -O 0x00000006 -T mpls0
Bind Tunnel2Out add: Success

[root <at> impls mpls]# cd iproute2/ip
[root <at> impls ip]# ./ip route add 172.16.1.0/24 dev mpls0


proc entries :

[root <at> impls utils]# cat /proc/net/mpls_out
0x00000005 457/38388/0 2 PUSH(gen 1024) SET(eth1,192.168.0.1)
0x00000006 84/7056/0 2 PUSH(gen 2048) SET(mpls0,0.0.0.0)

[root <at> impls utils]# cat /proc/net/mpls_tunnel
mpls0   0x00000006

on pinging the tunnel end point 192.168.0.1 packet does not come out of the interface at all.

Even if i ping 172.16.1.1 as given in the above command.

Please let me if i am doing something wrong in configuring the tunnel.

If i want to introduce one more LSR between LSR1 and LSR2, what kind of configuration changes do i need to do?.   something like
    
LSR1<----->LSR2<------>LSR3
 |          simple LSP          |
 |                                     |
 |<--------------------------------->|
              TUNNEL

  As for as the virtual interface is concerned there must be a route to reach the destination 192.168.0.2, and the out going interface would be eth1 as given in the above configuration, please correct if i am worng. So when packet received at LSR2 what kind of processing would be performed on the packet.I would like to know how to configure at LSR1 and LSR2 to process the incoming label properly, It will be great if somebody can provide me the command sequence.

Please find the debug out put( for ping 192.168.0.2) given bellow for the problem i mentioned earlier while creating mpls tunnel between 2 linux machines :

mpls_output2: enter
mpls_output2: opcode PUSH
mpls_push: enter
mpls_push: using tailroom
mpls_push: done using tailroom
mpls_push: exit
mpls_output2: opcode SET
mpls_send: output device = mpls0
mpls_finish: enter
mpls_finish: exit
mpls_send: GEN
mpls_send: using neighbour (cefdec80)
mpls_skb_dump: from mpls0 with len 88 (284) headroom=16 tailroom=24
3c373e4a756e2020332031363a30303a{|0080*01ff450000540000400040016771#c0a800020a01088d0800bef1530405007a148244f3ad060008090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363700}
mpls_send: mpls_send result 0
mpls_output2: exit
./mplsadm2 -d
Debug: Success


Thanks in advance for your help,
LSReddy.


_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Tom Petch | 6 Jun 12:18 2006

Re: Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

I am curious about the choice of prefix for these object descriptors, a mix of
mplsTe
mplsP2mp
mplsMP2p
I find this hard to follow and would prefer a single prefix (although I realise
there are ample precedents in MPLS:-)  - is there an underlying logic?

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <adrian <at> olddog.co.uk>
To: <mpls <at> lists.ietf.org>
Cc: "Thomas D. Nadeau" <tnadeau <at> cisco.com>
Sent: Thursday, June 01, 2006 12:59 AM
Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

> Hi,
>
> We have put together a first (somewhat rough) stab at defining a MIB module
> for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB modules are
> used in support of P2MP MPLS-TE. Hopefully the existence of this I-D will
> help the P2MP MPLS-TE solutions work along its path to becoming an RFC.
>
> Please review, comment, implement (!) and tell us what we have done wrong.
>
> Cheers,
> Adrian
>
> ----- Original Message -----
> From: <Internet-Drafts <at> ietf.org>
> To: <i-d-announce <at> ietf.org>
> Sent: Wednesday, May 31, 2006 8:50 PM
> Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt
>
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >
> > Title : Point-to-Multipoint Multiprotocol Label
> >                          Switching (MPLS) Traffic Engineering (TE)
> >                          Management Information Base (MIB) module
> > Author(s) : A. Farrel, et al.
> > Filename : draft-farrel-mpls-p2mp-te-mib-00.txt
> > Pages : 36
> > Date : 2006-5-31
> >
> >   This memo defines a portion of the Management Information Base
> >   for use with network management protocols in the Internet community.
> >   In particular, it describes managed objects for point-to-multipoint
> >   Multiprotocol Label Switching-based traffic engineering.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te-mib-00.txt
> >

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Thomas D. Nadeau | 6 Jun 17:51 2006
Picon

Re: Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt


	Hey it compiles cleanly so stop complaining! *)

	Yes, we will make the prefixes consistent.

	--Tom

> I am curious about the choice of prefix for these object  
> descriptors, a mix of
> mplsTe
> mplsP2mp
> mplsMP2p
> I find this hard to follow and would prefer a single prefix  
> (although I realise
> there are ample precedents in MPLS:-)  - is there an underlying logic?
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Adrian Farrel" <adrian <at> olddog.co.uk>
> To: <mpls <at> lists.ietf.org>
> Cc: "Thomas D. Nadeau" <tnadeau <at> cisco.com>
> Sent: Thursday, June 01, 2006 12:59 AM
> Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt
>
>
>> Hi,
>>
>> We have put together a first (somewhat rough) stab at defining a  
>> MIB module
>> for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB  
>> modules are
>> used in support of P2MP MPLS-TE. Hopefully the existence of this I- 
>> D will
>> help the P2MP MPLS-TE solutions work along its path to becoming an  
>> RFC.
>>
>> Please review, comment, implement (!) and tell us what we have  
>> done wrong.
>>
>> Cheers,
>> Adrian
>>
>> ----- Original Message -----
>> From: <Internet-Drafts <at> ietf.org>
>> To: <i-d-announce <at> ietf.org>
>> Sent: Wednesday, May 31, 2006 8:50 PM
>> Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt
>>
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title : Point-to-Multipoint Multiprotocol Label
>>>                          Switching (MPLS) Traffic Engineering (TE)
>>>                          Management Information Base (MIB) module
>>> Author(s) : A. Farrel, et al.
>>> Filename : draft-farrel-mpls-p2mp-te-mib-00.txt
>>> Pages : 36
>>> Date : 2006-5-31
>>>
>>>   This memo defines a portion of the Management Information Base
>>>   for use with network management protocols in the Internet  
>>> community.
>>>   In particular, it describes managed objects for point-to- 
>>> multipoint
>>>   Multiprotocol Label Switching-based traffic engineering.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te- 
>>> mib-00.txt
>>>

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Adrian Farrel | 7 Jun 03:08 2006
Picon

Re: Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

Tom,

>I am curious about the choice of prefix for these object descriptors, a mix 
>of
> mplsTe
> mplsP2mp
> mplsMP2p
> I find this hard to follow and would prefer a single prefix (although I 
> realise
> there are ample precedents in MPLS:-)  - is there an underlying logic?

The (impeccable) logic is simply that when you bash out code in a hurry you 
make some errors in things like naming.

Adrian 

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

黄郑 | 7 Jun 12:32 2006

Problem about the collision between multicast and unicast label

   In multicast, all downstream can be allocated the same label value in order to avoiding branch LSR traffic
replication on a LAN for point-to-multipoint (P2MP)LSPs. 
   The series documents of mpls upstream label are already made for wg docs. 
   Through upstream label assignment or downstream label assignment (based on upstream label suggestion), 
all next-hop downstream routers will receive and process the packet with the same label.

   But if unicast label is allocated before multicast label, it is possible that the same label will be
allocated on the same LSR for unicast LSP and multicast LSP on the same link. 
   The unicast LSP and the multicast LSP will use the same incoming label on the same interface. 

For example:
 
                                D 
                               / 
                              /   
                         A---B---C---E 
                              \      
                               \     
                                F 

   There already exists one unicast LSP (A-B-C-E). And the incoming label on LSR C is equal to K.
   There also exists one multicast tree (A-B, B-D, B-F). And the incoming label on LSR D and LSR F is equal to K.
LSR D and LSR F are the next hop downstream router of LSR B, and their incoming labels must  be same. 
   Subsequently, LSR C wants to join the multicast tree. LSR C is also the next hop downstream router of LSR B.
The incoming multicast label on LSR C must be equal to K, just like LSR D and LSR F on the same multicast tree.
   So there will appear the same incoming labels on LSR C if we don’t distinguish between multicast and unicast.

----------------------------------------------------------------------------------------------------------------
   In order to distinguish between multicast and unicast LSPs with the same label value, the labels can be
differentiated by the use of different Ethertypes that indicate whether the labeled packet that is
carried in a layer 2 frame is for unicast or multicast transfer. 
   But if LSR does not support these procedures, it can't discern the labeled packet and must ignore it. 
   On the other hand, the process of layer 2 frame is complex.
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Tom Petch | 7 Jun 12:25 2006

Re:I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

----- Original Message -----
From: "Adrian Farrel" <adrian <at> olddog.co.uk>
To: <mpls <at> lists.ietf.org>
Cc: "Thomas D. Nadeau" <tnadeau <at> cisco.com>
Sent: Thursday, June 01, 2006 12:59 AM
Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt
>
> We have put together a first (somewhat rough) stab at defining a MIB module
> for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB modules are
> used in support of P2MP MPLS-TE. Hopefully the existence of this I-D will
> help the P2MP MPLS-TE solutions work along its path to becoming an RFC.
>
> Please review, comment, implement (!) and tell us what we have done wrong.

Looks good, impressive even for a rough stab:-)

Some minor doubts

1) Why is mplsP2mpTunnelSubGroupIDNext limited to (0..65535) when
mplsP2mpTunnelSubGroupID has a range of (1..4294967295)?

2) mplsP2mpTunnelDestEntry has an awesome INDEX which is fine but I think that
the two InetAddress - mplsP2mpTunnelSubGroupOrigin and
unnelDestination          - need SIZE constraints in order to keep SMI happy.

3)  mplsP2mpTunnelBranchOutSegment  is of SYNTAX MplsIndexType ie OCTET STRING
so the special values should be 'single octet with the value 0x00' as in
RFC3813.

4) I wonder if the meaning of the special value "that MIB module is inaccessible
or not implemented." is not too strict.  Could there not be other circumstances
when the table as a whole is accessible but the relevant row is not?

5) mplsP2mpTunnelDestCreationTime should reference sysUpTime.

6)  Several Counter32 have a  DESCRIPTION
           "Specifies the number of times the ..."
I never like 'specifies' sinces it begs the question of since when, and being a
counter, there is no when.  Counters, by definition, are only meaningful when
read more than once and differenced.  (RFC3813, along with other Mib Modules,
avoids this word).

7) Again on counters, particularly for mplsP2mpTunnelBranchPerfEntry, should
there be a discontinuity object?

8) I am puzzled why mplsP2mpTunnelDestUp and mplsP2mpTunnelDestDown are defined
in terms of down state.  It means, for example, that the transition from down to
testing or lowerLayerDown would generate an Up NOTIFICATION; odd.

9)  mplsP2mpTunnelDestOperStatus lacks values 5 and 6; I suggest adding a note
that this enumeration is in line with RFC3812 where those values are in use.

Tom Petch

>
> Cheers,
> Adrian

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Adrian Farrel | 7 Jun 18:23 2006
Picon

Re: Re:I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt

Hi Tome,

> Some minor doubts
>
> 1) Why is mplsP2mpTunnelSubGroupIDNext limited to (0..65535) when
> mplsP2mpTunnelSubGroupID has a range of (1..4294967295)?

Because I changed the size of SubGroupID and forgot about IDNext.

> 2) mplsP2mpTunnelDestEntry has an awesome INDEX which is fine but I think 
> that
> the two InetAddress - mplsP2mpTunnelSubGroupOrigin and
> unnelDestination          - need SIZE constraints in order to keep SMI 
> happy.

Probably right. And a good thing anyway.

> 3)  mplsP2mpTunnelBranchOutSegment  is of SYNTAX MplsIndexType ie OCTET 
> STRING
> so the special values should be 'single octet with the value 0x00' as in
> RFC3813.

Good catch

> 4) I wonder if the meaning of the special value "that MIB module is 
> inaccessible
> or not implemented." is not too strict.  Could there not be other 
> circumstances
> when the table as a whole is accessible but the relevant row is not?

Hmmm. Not sure. I guess this requires a careful parse of the compliance in 
that module.

> 5) mplsP2mpTunnelDestCreationTime should reference sysUpTime.

Yes.

> 6)  Several Counter32 have a  DESCRIPTION
>           "Specifies the number of times the ..."
> I never like 'specifies' sinces it begs the question of since when, and 
> being a
> counter, there is no when.  Counters, by definition, are only meaningful 
> when
> read more than once and differenced.  (RFC3813, along with other Mib 
> Modules,
> avoids this word).

Actually, I probably cutted and pasted this from one of the MPLS MIB 
modules.
But you are right.

> 7) Again on counters, particularly for mplsP2mpTunnelBranchPerfEntry, 
> should
> there be a discontinuity object?

Yes.

> 8) I am puzzled why mplsP2mpTunnelDestUp and mplsP2mpTunnelDestDown are 
> defined
> in terms of down state.  It means, for example, that the transition from 
> down to
> testing or lowerLayerDown would generate an Up NOTIFICATION; odd.

Good thing to be puzzled about.
I was aiming for consistency with the MPLS TE MIB module.

> 9)  mplsP2mpTunnelDestOperStatus lacks values 5 and 6; I suggest adding a 
> note
> that this enumeration is in line with RFC3812 where those values are in 
> use.

Yes.

Very many thanks.
Adrian

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Fil Dickinson | 8 Jun 04:19 2006
Picon

RE: Problem about the collision between multicast and unicastlabel

I agree (based on your example) we need a mechanism to distiguish
Unicast labels from Multicast, but are there not better ways to do it
than "Ethertype" such as defined label ranges or something related to
the problem rather than a clever use of an unrelated field?
I do not have an answer, but perhaps others have thought of this. 

-----Original Message-----
From: szhuangzheng <at> huawei.com [mailto:szhuangzheng <at> huawei.com] 
Sent: Wednesday, 7 June 2006 8:32 PM
To: mpls <at> lists.ietf.org
Subject: [mpls] Problem about the collision between multicast and
unicastlabel

   In multicast, all downstream can be allocated the same label value in
order to avoiding branch LSR traffic replication on a LAN for
point-to-multipoint (P2MP)LSPs. 
   The series documents of mpls upstream label are already made for wg
docs. 
   Through upstream label assignment or downstream label assignment
(based on upstream label suggestion),  all next-hop downstream routers
will receive and process the packet with the same label.

   But if unicast label is allocated before multicast label, it is
possible that the same label will be allocated on the same LSR for
unicast LSP and multicast LSP on the same link. 
   The unicast LSP and the multicast LSP will use the same incoming
label on the same interface. 

For example:

                                D 
                               / 
                              /   
                         A---B---C---E 
                              \      
                               \     
                                F 

   There already exists one unicast LSP (A-B-C-E). And the incoming
label on LSR C is equal to K.
   There also exists one multicast tree (A-B, B-D, B-F). And the
incoming label on LSR D and LSR F is equal to K. LSR D and LSR F are the
next hop downstream router of LSR B, and their incoming labels must  be
same. 
   Subsequently, LSR C wants to join the multicast tree. LSR C is also
the next hop downstream router of LSR B. The incoming multicast label on
LSR C must be equal to K, just like LSR D and LSR F on the same
multicast tree.
   So there will appear the same incoming labels on LSR C if we don't
distinguish between multicast and unicast.

------------------------------------------------------------------------
----------------------------------------
   In order to distinguish between multicast and unicast LSPs with the
same label value, the labels can be differentiated by the use of
different Ethertypes that indicate whether the labeled packet that is
carried in a layer 2 frame is for unicast or multicast transfer. 
   But if LSR does not support these procedures, it can't discern the
labeled packet and must ignore it. 
   On the other hand, the process of layer 2 frame is complex.

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls


Gmane