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

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

problem configurating tunnel using mplsadm2 and iproute2

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

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

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

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

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

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

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

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